ARTSN: An Automated Real-Time Spacecraft Navigation System

Introduction

A prototype effort was started in the Telecommunications and Mission Operations (TMO) Navigation Work area to demonstrate a new class of navigation software for automated real-time interplanetary spacecraft navigation (ARTSN). The motivation for the development of ARTSN is efficiency. This tool makes it possible for the navigation operations analyst to switch from a mode of constant oversight to exception monitoring, thus enabling him to support additional spacecraft, simultaneously. Also, the ability of the automated system to provide faster orbit solution generation, than manual systems, allows for a greater ability to support missions that have a short turnaround between the occurrence of a critical event and the generation of a required response to that event.

ARTSN Paradigm

Historically, all interplanetary missions have made use of ground-based radio metric data, such as Doppler and range. Additionally, some missions have made use of optical images of target bodies against a known star field, telemetered to the Earth for processing, to provide target relative position information. With all of these data types, the information is electronically transferred to a ground operations facility, where the data is buffered and stored until processed; the latency between observation time and processing time may be from as little as 10 minutes to as long as a few months (depending on the needs of the mission), with 12-24 hours being typical.

Newly received data is merged with already analyzed data and the entire data set is processed via a batch-sequential least squares estimator. In this process, the identification and deletion of invalid data as well as the operation of the software is performed by an analyst operating at a workstation console. The process of fitting the data requires the use of multiple software links and the manual examination of prefit residuals, to determine which points should be fit and which points should be deleted from the solution. After generating the best estimate of the spacecraft trajectory, based on the input models, the analyst must determine the appropriate set of output coordinate frames and mappings that are desired to view the solution and use the software to generate postfit residuals. Typically, this process requires approximately one hour of additional processing time after the data is received by the operations analyst. When it is necessary to evaluate multiple models, as is the normal procedure, multiple analysts must work in parallel, or additional processing time is required.

While recent missions have begun to institute greater automation of portions of the process, the nature of the automation focuses on the use of scripts and automated routines that use the underlying software instead of the development of a robust system intended for automated use. Although such automated systems have been developed for Earth orbiting missions, they have not previously existed for interplanetary missions. With such a system, one could automate the generation of predicted spacecraft positions for ground stations, provide an operational tool for fast turn-around applications, and become a 'stepping stone' to an onboard interplanetary navigation system.

Development History

The conceptual design of ARTSN began in 1994 at JPL. The resulting design, known as RTAF (Real-Time Automated Filter) [Ref.], brought out several key lessons learned:

• Modularize the architecture of the system whenever possible.
• Separate the data output and control user interfaces from the primary analysis system.
• Use commercial software when possible.
• Streamline the process for addition of new force and observable models.

From RTAF, the next step was to build the ARTSN prototype, with the short-term objective of demonstrating automated radiometric data processing for interplanetary cruise. From the lessons learned came two tenets of the ARTSN design:

• Integrate the (historically) separate modules into a single package. Merging the links that provide trajectory propagation, station location computation, measurement modeling, filtering, and state and covariance mapping facilitate the real-time capability.
• Use modern software techniques to implement the existing algorithms. The resulting highly modular components can be modified easily and arranged to work in a distributed environment.

ARTSN Characteristics

Figure 1 shows the ARTSN components, as well as the data flow throughout. The interaction between the components is handled with machine portable data structures through TCP/IP network connections. The data preprocessor, known as ARTOG (Automated Real-Time Observable Generator), creates measurement records from the raw DSN TRK-2-15A stream. ARTOG performs simple data validation checks and supplies ramps and a time-ordered sequence of Doppler and range data. The ARTSN shell is a command-line style interactive user interface that translates namelist inputs into engine-remote procedure calls. The ARTSN engine is where the integrations, observable computations, filterings, and mappings are performed, separate from the user interface; thus, the input and output processes can be modified for specific projects and users without modifying the engine. The displays for this prototype are LabVIEW graphical applications; any package with a network interface (such as Java) can be used to create an ARTSN real-time display. By using remote procedure calls, the displays configure the engine to send the correct data stream back to them without user interaction directly with the engine. Front- and back-end displays can be implemented on relatively inexpensive desktop PCs while the engine runs on a workstation.

A feature of the ARTSN software architecture is the standardization of the module interfaces, which allows new modules to be added quickly by any programmer that adheres to the interface standard. Changes and additions can be propagated by using the interface; this helps eliminate unsupported programs and versions and allows for more efficient configuration management.

A third feature of the ARTSN architecture is the generic participant structure. A participant can be a spacecraft, ground station, or natural body. No assumptions are made on what participants exist, or what their relationships are to other participants. This enables support for scenarios with multiple spacecraft, asteroids with moons, comets, etc. This arbitrary participant structure enables:

• Multiple spacecraft simulations
• Measurements between any participants
• Mapping events between any participants
• Addition of new propagator types

ARTSN Use

1. A preliminary validation of ARTSN was performed by comparing it with the existing operations software. The agreement between the software suites was at the numerical precision level. Specific validation checks included:
   • Trajectory and transition matrix integration
   • Observable and partial generation
   • Batch filtering
   • State and covariance mapping
2. After this validation, a 'real world' test was performed, where ARTSN was fed inputs from the Mars Pathfinder navigation team to produce current state and epoch state solutions over a 76-day data arc. The ARTSN solutions were used to make encounter estimates. In both modes, the ARTSN estimate agreed with that generated by the Pathfinder navigation team to within less than half of the Pathfinder estimate uncertainty.
3. A presentation was given to the navigation section in July 1997. The results of Case 2 were reported, and a demonstration was performed using an unedited recording of a DSN broadcast of the final two weeks of the Mars Pathfinder cruise. This time span included the final maneuver, TCM-4, and a patch of data corrupted by the improper application of a leap second correction. As the data were processed, the solution evolved, which accounted for the maneuver and rejection of most of the corrupted data.
4. The Mars Global Surveyor (MGS) navigation team demonstrated real-time navigation using ARTSN during the Mars Orbit Insertion (MOI) on September 11, 1997, and during the aerobraking phase of the mission to date. ARTSN read radio metric Doppler data in real time and computed measurements based on an ARTSN-generated nominal trajectory. Streams of observable and residual values were piped to several displays in real-time, both to the public (Figure 2) and the navigation analysts themselves.
5. The MGS navigation team continued to use the ARTSN displays to monitor aerobraking-related events, such as periapsis-lowering maneuvers, and tracking before and after each periapsis pass. The line-of-sight Doppler shifts during the maneuvers were reported back to the project as a 'quick-look' assessment of the event, and the effective Doppler shift from each aerobraking pass was also monitored as tracking resumed after each pass.

FY98 Plans

The vision for ARTSN for the next year includes an expansion of its capabilities and more demonstrations of its utility and workforce savings (pending the resolution of funding issues). There are sets of rapid turnaround applications where a real-time capability can make a strong impact, including additional aerobraking monitoring for MGS, launch support, general maneuver monitoring, and approach navigation. Second, there are scenarios where an autonomous or nearly autonomous presence would be of benefit, such as spacecraft trajectory predictions for ground tracking stations or autonomous orbit determination for a spacecraft in a long, quiet, cruise phase.

Reference

Masters, W. C., and V. M., Pollmeier, "Development of a Prototype Real-Time Automated Filter for Operational Deep Space Navigation," Third International Conference on Space Mission Operations and Ground Data Systems, Goddard Space Flight Center, Greenbelt, MD, 14-18, November 1994.

• Top of Page
• Return to Homepage

• TMOD Reorganization: Changes for the Better
• Improvement in the Water Vapor Emission Model from GPS/WVR Comparisons
• Raster-Scan for Calibration of DSN Antennas
• Space VLBI Co-Observing at the DSN