Full report

Original page 1

NASA/TM–2005–213715 Three Years of Global Positioning System Experience on International Space Station Susan Gomez NASA/Johnson Space Center December 2005

Original page 2

The NASA STI Program Office . . . in Profile Since its founding, NASA has been dedicated to the advancement of aeronautics and space science. The NASA Scientific and Technical Information (STI) Program Office plays a key part in helping NASA maintain this important role. The NASA STI Program Office is operated by Langley Research Center, the lead center for NASA’s scientific and technical information. The NASA STI Program Office provides access to the NASA STI Database, the largest collection of aeronautical and space science STI in the world. The Program Office is also NASA’s institutional mechanism for disseminating the results of its research and development activities. These results are published by NASA in the NASA STI Report Series, which includes the following report types: • TECHNICAL PUBLICATION. Reports of completed research or a major significant phase of research that present the results of NASA programs and include extensive data or theoretical analysis. Includes compilations of significant scientific and technical data and information deemed to be of continuing reference value. NASA’s counterpart of peerreviewed formal professional papers but has less stringent limitations on manuscript length and extent of graphic presentations. • TECHNICAL MEMORANDUM. Scientific and technical findings that are preliminary or of specialized interest, e.g., quick release reports, working papers, and bibliographies that contain minimal annotation. Does not contain extensive analysis. • CONTRACTOR REPORT. Scientific and technical findings by NASA-sponsored contractors and grantees. • CONFERENCE PUBLICATION. Collected papers from scientific and technical conferences, symposia, seminars, or other meetings sponsored or cosponsored by NASA. • SPECIAL PUBLICATION. Scientific, technical, or historical information from NASA programs, projects, and mission, often concerned with subjects having substantial public interest. • TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific and technical material pertinent to NASA’s mission. Specialized services that complement the STI Program Office’s diverse offerings include creating custom thesauri, building customized databases, organizing and publishing research results . . . even providing videos. For more information about the NASA STI Program Office, see the following: • Access the NASA STI Program Home Page at http://www.sti.nasa.gov • E-mail your question via the Internet to help@sti.nasa.gov • Fax your question to the NASA Access Help Desk at (301) 621-0134 • Telephone the NASA Access Help Desk at (301) 621-0390 • Write to: NASA Access Help Desk NASA Center for AeroSpace Information 7121 Standard Hanover, MD 21076-1320

Original page 3

NASA/TM–2005–213715 Three Years of Global Positioning System Experience on International Space Station Susan Gomez NASA/Johnson Space Center National Aeronautics and Space Administration Johnson Space Center Houston, Texas 77058-3696 December 2005

Original page 4

Available from: NASA Center for AeroSpace Information 7121 Standard Hanover, MD 21076-1320 National Technical Information Service 5285 Port Royal Road Springfield, VA 22161 This report is also available in electronic form at http://techreports.larc.nasa.gov/cgi-bin/TRS

Original page 5

I. Introduction 3 II. Other Programs or Experiments Using GPS Space Based Attitude Determination 5 III. Problems Encountered that Required Operator/Mission Control Intervention 7 A. Time Outputs Were Incorrect B. GPS/INS Output a Not-A-Number C. Numerous Power Cycles D. Low Position and Attitude Coverage E. Navigation Problems F. Velocity Noise Due To Ionospheric Scintillation 7 9 10 10 11 12 G. Multipath Interference Caused by the Robotic Arm 12 H. GPS/INS Impacts On Mission Control State Vector Ground Processing 13 I. Impacts of Poor State Vector Coverage Following Reboost 13 IV. Lessons Learned V. Conclusion Acknowledgments References 14 16 17 18

Original page 6

The International Space Station global positioning systems (GPS) receiver was activated in April 2002. Since that time, numerous software anomalies surfaced that had to be worked around. Some of the software problems required waivers, such as the time function, while others required extensive operator intervention, such as numerous power cycles. Eventually, enough anomalies surfaced that the three pieces of code included in the GPS unit have been re-written and the GPS units were upgraded. The technical aspects of the problems are discussed, as well as the underlying causes that led to the delivery of a product that has had numerous problems. The technical aspects of the problems included physical phenomena that were not well understood, such as the affect that the ionosphere would have on the GPS measurements. The underlying causes were traced to inappropriate use of legacy software, changing requirements, inadequate software processes, unrealistic schedules, incorrect contract type, and unclear ownership responsibilities. I. Introduction Traditionally, space vehicles use ground tracking to provide position and velocity information; and star trackers, sun sensors, Earth sensors, and/or magnetometers to provide attitude information. Ground tracking uses ground based antennas to determine the orbits of spacecraft, as well as orbital debris. The U.S. segment of International Space Station (ISS) has been using GPS as its primary source of information for position, velocity, 1 attitude, and time since April 2002 . The ISS GPS receiver procured by NASA is a GPS/Inertial Navigation System (GPS/INS). The GPS/INS architecture has been used successfully in military aircraft, tactical missile , and ground applications for the past 10 years. Other configurations have been used successfully on more than a dozen space 3 missions and are the primary navigator on multiple launch vehicles . The ISS, Crew Return Vehicle (CRV), and Shuttle GPS/INS units were the first developed for space applications. The GPS/INS procured by NASA was intended to provide a ‘common’ navigation sensor that would fulfill the Space Shuttle, ISS, and CRV requirements. In theory, a common navigation sensor would provide cost savings. For the Shuttle, the GPS/INS was to replace the High Accuracy Inertial Navigation System (HAINS) and the Miniaturized Airborne GPS Receiver (MAGR). For ISS, the GPS/INS is the primary navigation, attitude, and time sensor for the U.S. segment of the ISS. For the Crew Return Vehicle, the GPS/INS was to be the primary navigation and attitude sensor. Unfortunately, the goal of developing a common navigation sensor was never fully realized. Shuttle’s GPS/INS used a different GPS receiver than the ISS/CRV GPS/INS and therefore required a completely different software interface due to the requirement to maintain transparency with the heritage Shuttle avionics system. Originally, the ISS and CRV GPS/INS units were similar, and the software interface was intended to accommodate both projects. However, after three years of development, the throughput of one of the processors was not capable of implementing the diverse system requirements for both mission applications so the software between the two programs diverged. Although the hardware for ISS and CRV was similar, the ISS program did not initially have any requirements for the accelerometers or gyros in the GPS/INS. However, now that the unit is operational, the ISS program is attempting to use the accelerometer data from the INS to provide real time feedback during reboosts in the future. At the time of the delivery of the flight units, the only thing common between the GPS/INS units for all three programs was the inertial sensor hardware, which is still currently unused by ISS. Shuttle GPS/INS was cancelled after the GPS/INS phase 1 flight test and development program was 2 completed . CRV GPS/INS was cancelled when the CRV project was canceled in 2002. The Space Shuttle still uses its two star trackers to determine attitude and align the HAINS. The GPS/INS procurement for Space Shuttle was not intended to replace the star tracker functionality, only the HAINS and MAGR. The ISS does have star tracker, sun sensor, Earth sensor, and magnetometer assets on the Russian

Original page 7

Segment that provide valuable independent attitude knowledge during time periods when the GPS attitude functionality is not usable. This paper will focus on the ISS GPS/INS. Lessons learned from Shuttle GPS/INS and Shuttle GPS can be found in References 4-7. For ISS, the GPS position and velocity solutions from the two GPS receivers are used as updates to the ISS flight software’s propagated orbital state, the GPS attitude solutions are used as inputs in the ISS flight software’s attitude filter, and the GPS time output is used to correct the ISS on-board clocks. The GPS position, velocity, and attitude solutions are all unfiltered when received by the ISS flight software, which then filters the position, Inertial Sensor Assembly - Gyros, Accelerometers, and Inertial Electronics J4 RF1 To Analog Navigation 1 PPS RF2 to Processor AA ORUs RF3 Digital (4) RF4 Attitude GPS Processor Receiver J1 DC Power Converter – ACOCS Power System Processor J3 1553B ADDRESS JUMPERSGN&C MDM 1553B 1553 A&B Chip Set OFP US Lab Supplies DC to all the Power Converter +28 subassemblies +120 VDC VDC Fig. 1 Block diagram of ISS GPS/INS. velocity, and attitude information for on-board use. Future releases of the ISS software will include a filter for time so that the time output can be used autonomously (currently the time output is only used when the operators manually sync the on-board clocks to the GPS/INS time output). For the ISS GPS/INS, the GPS receiver manufacturer provided the GPS hardware and the GPS navigation software. NASA provided the GPS attitude software that resides within the GPS receiver. The GPS/INS integrator provided the integrated GPS/INS, the INS hardware, as well as the System Processor (SP) software that reads in the GPS receiver data and formats it for output over the MIL-STD 1553B bus. The data from the GPS receiver navigation firmware are passed through the GPS attitude firmware to the SP. The SP software also included the Kalman filter needed by CRV to blend the inertial and GPS measurements, and a GPS-only filter intended for use on ISS. The GPS-only Kalman filter was never used by ISS due to operational complexities associated with using it. Figure 1 shows a block diagram of ISS GPS/INS and Figure 2 shows the ISS and the GPS Antenna Assemblies (AA). After three years of on-orbit experience, the GPS continues to be used as the primary navigation, attitude, and time data source for ISS; however, some problems surfaced during operations that were not discovered during preflight simulation tests or Space Shuttle flight tests. As a result, the software in the GPS attitude code was totally Fig. 2 ISS GPS subsystem.

Original page 8

rewritten using a code standard, and new GPS attitude algorithms were developed that are uniquely suited for ISS. In addition, the software that processes the time output from the GPS receiver was rewritten, while the GPS navigation code received minor revisions. The re-written code has been delivered to the ISS program and the GPS/INS units were upgraded with the new software in November 2004 for the first unit and February 2005 for the second unit. The new software has had substantially fewer problems as will be discussed later. Table 1 ISS Navigation Requirements Semi major axis accuracy Position accuracy Attitude accuracy Time Accuracy 1000 feet 3 sigma 3000 feet 3 sigma 0.5 degrees 3 sigma 100 microseconds 3 sigma The requirements for the ISS are shown in Table 1. GPS alone can meet the semi-major axis and time requirements. However, the multipath environment on ISS is such that the unfiltered GPS attitude solutions can not meet the 0.5 degree requirement. Unfiltered GPS attitude data is filtered with rate gyro data by the ISS software, resulting in an attitude output which does meet the 0.5 degree requirement. The GPS implementation on the ISS includes four GPS antennas as seen in Figure 2. Three GPS antennas are required for three dimensional attitude determination calculations and one antenna is required for position, velocity, and time calculations. There are two GPS/INS units in the United State’s Lab Module, also shown in Figure 2. For manned space flight, the requirement is for a system to be two-fault tolerant, meaning that following two faults, the system still meets requirements. For the ISS implementation, the Russian Segment avionics provide the third string of redundancy so that if both of the U.S. GPS/INS units fail, the ISS can still navigate using the Russian assets. Prior to the activation of the GPS/INS units in April 2002, the ISS navigated and determined attitude safely using the Russian segment alone. Figure 3 shows a diagram of the U.S. and Russian segment navigation and attitude determination assets. Sensors ISS Software/Computers Russian Attitude Sensors Russian ISS Control Attitude Star Trackers Determination SoftwareRussian Attitude Sun Sensors Attitude QuaternionDetermination SoftwareRussian Attitude Earth Sensors Attitude QuaternionDetermination Software Magnetometer Attitude Rate Gyros Quaternion Russian Thrusters Russian Navigation Russian Navigation Sensors SoftwareRussian Navigation Ground Tracking SoftwareRussian Navigation ISS Orbital State Vector GLONASS/GPS(not ISS Orbital State VectorSoftware operational yet) ISS Orbital State Vector US US Attitude Sensors Attitude US Control Moment Determination SoftwareUS Attitude Gyros GPS Attitude QuaternionDetermination Software Rate Gyros Attitude Quaternion US Navigation Sensor US Navigation Software GPS ISS Orbital State VectorUS Navigation Software ISS Orbital State Vector Fig. 3 ISS GNC overview.

Original page 9

Sensors ISS Software/Computers Russian Attitude Sensors Russian ISS Control Attitude Star Trackers Determination SoftwareRussian Attitude Sun Sensors Attitude QuaternionDetermination SoftwareRussian Attitude Earth Sensors Attitude QuaternionDetermination Software Magnetometer Attitude Rate Gyros Quaternion Russian Thrusters Russian Navigation Russian Navigation Sensors SoftwareRussian Navigation Ground Tracking SoftwareRussian Navigation ISS Orbital State Vector GLONASS/GPS(not ISS Orbital State VectorSoftware operational yet) ISS Orbital State Vector US US Attitude Sensors Attitude US Control Moment Determination SoftwareUS Attitude Gyros GPS Attitude QuaternionDetermination Software Rate Gyros Attitude Quaternion US Navigation Sensor US Navigation Software GPS ISS Orbital State VectorUS Navigation Software ISS Orbital State Vector Fig. 3 ISS GNC overview. Notice that the Russian Segment has three sets of computers for fault tolerance while the U.S. side has only two. The Russian segment was the first deployed and had to meet the two fault tolerant requirement in the absence of any U.S. assets. The U.S. and Russian segments exchange information. The U.S. segment can be in control (i.e., using the Control Moment Gyros to maintain attitude) while using the Russian attitude information as the source of attitude knowledge. Likewise, the Russian segment can be using thrusters to control attitude while using the U.S. attitude information as the source of attitude knowledge. The Russian segment has a much wider range and redundancy of sensors. II. A Brief History of GPS Space Based Attitude Determination

Original page 10

8 GPS attitude determination for spacecraft was demonstrated as feasible by RADCAL in 1995 . GPS attitude 9,10 determination for use in a closed loop control system was first demonstrated by the REX II spacecraft in 1996 . In preparation for determining the appropriateness of attempting to use a new technology for attitude determination on ISS, NASA expended considerable effort and resources to test GPS receivers on the Space Shuttle. STS-77 flew a predecessor to the GPS receiver used on ISS. The receiver was mounted in the Shuttle payload bay with 4 GPS 11,12,13 antennas arranged in the same 1.5 meter by 3 meter configuration that the ISS uses . The same GPS/INS unit that ISS uses was flown on STS-101 and STS-106 configured with the same software as the ISS GPS/INS units used when they were activated in April 2002. These two flights also had the GPS/INS mounted in the Shuttle payload bay with four GPS antennas arranged in a 1.5 meter by 3 meter rectangle to mimic the ISS GPS anten na GPS Antennas Star Trackers GPS Antennas GPS/INS 1,14,15 configuration . Two additional flight tests were performed on STS-100 and STS- 108 using the same GPS/INS hardware, but the GPS/INS was mounted in a Shuttle avionics rack and was configured to use Fig. 4 Space Shuttle payload bay arrangement for STS-101 and STS-106. the Shuttle’s Miniature Airborne GPS Receiver (MAGR) GPS antennas. The STS-100 and STS-108 flight tests were primarily flown to demonstrate the entry performance of the GPS/INS for use on CRV: GPS attitude determination was not 1 demonstrated on these flights . Figure 4 shows the arrangement of the four GPS antennas and the mounting platform for the STS-101 and STS- 106 missions. The antennas and the antenna configuration were the same for STS-77. The GPS attitude solutions were compared to star tracker solutions for STS-101 and STS-106. STS-77 did not fly a star tracker, and the Shuttle’s attitude solution was used for comparison for that experiment. In addition to the flight tests, the GPS/INS code was put through extensive ground testing. The formal test suite included four months of orbital simulations using a GPS RF signal generator and one month of testing using a roof top antenna. Informal testing was conducted over several years and included both roof top antenna testing and orbital simulations. NASA also conducted independent testing of the entire ISS Guidance, Navigation, and Control (GNC) System in a closed-loop environment using as much ISS hardware as possible, including two GPS/INS units. This testing has been on going since 2000. Despite this extensive testing which uncovered more than 200 anomalies, some problems were nonetheless encountered after the GPS units were activated on the ISS in April 2002. The next section describes the problems that were uncovered after the product had been delivered and accepted. A brief timeline of the significant milestones in the ISS GPS/INS development is shown in Table 2. Significant Events in ISS GPS/INS Timeline STS-77 May 1996 Demonstrate GPS attitude capability STS-101 and STS-106 May and Sept. 2000 Demonstrate the ISS GPS/INS in a space environment performing attitude determination

Original page 11

STS-100 and STS-108 May and Dec. 2001 Demonstrate the GPS/INS capability for CRV Activation of ISS GPS/INS units April 2002 Both ISS GPS/INS activated and on the ISS incorporated into the U.S. segment of the ISS New firmware loaded into the Nov. 2004 and Feb. 2005 Due to the many problems uncovered ISS GPS/INS units before and after the units were activated on the ISS, new firmware was developed and loaded into the units on orbit III. Problems Encountered that Required Operator/Mission Control Intervention A. Time Outputs Were Incorrect Time is critical to many applications on ISS, such as solar panel pointing and communication antenna pointing. After the GPS/INS had been activated by the ISS program, numerous time problems were uncovered. Fortunately, time problems previously uncovered during the flight tests on the Shuttle and ground testing led to the time requirement being waived. Had the ISS been configured to use the time from the GPS/INS autonomously, the time problems uncovered could have put the ISS at risk. However, the time function was managed using an alternate manual technique. The central clock for the U.S. segment of the ISS is the clock of the Primary Command and Control (C&C) computer, which is a radiation hardened Intel 386-based machine that broadcasts time to all other U.S. segment computers and other devices via the MIL-STD 1553B network. The clock of the C&C is not intended to be precise, and can have a clock drift of up to one second per day uncorrected. The C&C code was designed to be synched to GPS/INS and automatically track GPS time output, thus negating the need for a precision clock within the C&C itself. However, because the time outputs from GPS/INS have been so erratic, the C&C clock has never been autonomously synched to GPS/INS. Instead, flight controllers leave the C&C clock in local mode (where the local clock is allowed to drift and is not reset by the time output from GPS/INS). The drift can be coarsely metered in a positive or negative direction through daily manual adjustment commanded by the ground. Flight controllers compute onboard time error by comparing timestamps on downlink telemetry to the Mission Control Center central timing system and adjusting the clock metering rate daily. Using this workaround, the C&C clock is kept to within +/- 2 seconds of GPS system time. The error is acceptable, but is outside design specifications. Fortunately, the payloads that require the tighter requirement have not yet been deployed. Each of the time anomalies is discussed in detail below. The first time anomaly uncovered was that the output from the GPS/INS would not jump back to the correct time following long periods of tracking fewer than four satellites. It generally took periods as long as 19 hours for the problem to surface. It was discovered that logic put in place in the SP to accommodate the time intervals when SP was not receiving a time message from the GPS receiver caused problems following long outages. The GPS receiver did not output the time message due to the particular implementation of the integer resolution algorithm in the GPS attitude firmware. Once the SP’s clock and GPS receiver’s clock had drifted apart by more than 3.5 seconds during the time message outages, the SP code didn’t think the time output it later received from the GPS was accurate, even though it was. During the time that the GPS attitude software, using an integer search

Original page 12

technique, is searching thru the integers, all interrupts are disabled, which also means that no messages, including the time message, are output. The time output from the GPS receiver could cease for as long as 10 seconds, which the SP code perceived as time jumps. The problem in the SP code was a result of the SP code attempting to accommodate these perceived time jumps due to the loss of time message outputs from the GPS attitude firmware. The second time anomaly uncovered was that the GPS/INS time was observed to jump by several seconds. The cause of this particular problem was never fully understood; however, since the time code has been totally rewritten the problem has not recurred. The third time anomaly uncovered was that the GPS/INS unit’s time was observed to jump by 1024 weeks, an entire GPS epoch. This was traced to code in the GPS/INS that was attempting to use GPS leap seconds to determine how many GPS rollovers had occurred. Figure 5 shows an example of the time data Fig. 5 GPS/INS time compared to ODRC time. from the GPS/INS on the ISS. The GPS/INS unit’s time is compared to the time stamp placed on the telemetered data by the Orbital Data Reduction Complex (ODRC). ODRC is the computer system in Mission Control that stores all of the flight data. The time stamp it places on the data is from its own clock, which is synced to Universal Time Coordinated (UTC). Notice the jump of 1024 weeks (1 GPS epoch) near the beginning of the plot. The data file for this plot contains the following: ODRC Time GPS/INS Seconds 2002_142:02:08:38.296 706068511 2002_142:02:08:39.296 706068512 2002_142:02:08:40.296 706068513 2002_142:02:08:41.296 706068514 2002_142:02:08:42.296 706068515 2002_142:02:08:43.296 706068516 time jump 2002_142:02:08:44.296 86753317 2002_142:02:08:45.296 706068518 2002_142:02:08:46.296 706068519 2002_142:02:08:47.296 706068520 2002_142:02:08:48.296 706068521 2002_142:02:08:49.296 706068522 2002_142:02:08:50.296 706068523 Notice the time output at 2002_142:02:08:44.296 in which the GPS/INS time jumps back in time 1024 weeks, but recovers on the subsequent output. The time problems within the SP code were corrected by completely redesigning the time function and the new

Original page 13

SP code has been tested in all of the scenarios that caused the problems noted above. This new code has been in use on the ISS since November 2004 with no recurrence of the problem. The new time design utilizes the time message from the GPS receiver, rather than using the time part of the position and velocity message. This new Fig. 6 Time error in microseconds when tracking at least 4 satellites. design does not suffer from the flaw that the time in the position RF Reconnected message is only updated when the receiver is able to calculate a position solution. Additionally, the new time design has been thoughtfully crafted to propagate time during position outages using the GPS receiver’s more stable oscillator, rather than the less stable SP oscillator. With the new design, the time propagates at the rate of the error in the last output of the GPS receiver’s oscillator drift rate. Previously, the SP propagated time using its clock, which drifts at approximately 35 microseconds per second, while the GPS receiver’s clock drifts at 1 to 2 microseconds per second. Under the new design, the time drifts at a lower rate than the drift rate of the GPS oscillator since the software compensates for the last measured drift rate. Unfortunately, one new problem has been uncovered that will occur when there are 15 leap seconds and will manifest itself as a time jump of entire GPS epochs. This problem will have to be corrected prior to the leap seconds reaching 15 (in a few years). Even though the GPS/INS units have been upgraded with the new software that fixes the time problems, the ISS is still not using the GPS/INS time autonomously. The time data from the GPS/INS units are being evaluated to ensure satisfactory software performance before attempting to use the time data autonomously. The original time design did meet the requirements when the GPS receiver was tracking enough satellites to determine position, and the requirements were written so that time only needed to meet requirements when the GPS receiver was determining position. Therefore, the software passed the initial tests, which were designed strictly to test conformance to the requirements. Subsequent tests have been designed that test the GPS/INS under conditions beyond the original requirements that are more strenuous and therefore more likely to detect problems. Figures 6 and 7 show the time error for the new GPS/INS code compared to a True Time GPS card during a static ground test. Figure 6 is for a time period when the GPS/INS is tracking at least four satellites, and Figure 7 includes a period when the Radio Frequency (RF) port was disconnected so that GPS/INS was not tracking satellites. RF Disconnected

Original page 14

Fig. 7 Time error in microseconds: GPS/INS RF port disconnected for weekend. B. GPS/INS Output a Not-A-Number On two occasions on February 11, 2003, almost an entire year after the activation of the GPS/INS units on the ISS, the GPS attitude code output an IEEE 754 Not-A-Number (0x7FFF 0xFFFF). The Not-A-Number output caused the U.S. primary and the backup ISS Guidance, Navigation, and Control (GNC) computers to stop processing. Attitude control was handed off from the Control Moment Gyroscope (CMG)-based system on the U.S. segment to the thruster-based system on the Russian segment, resulting in loss of micro-gravity and requiring the use of carefully managed propellant supplies for control. Flight controllers manually pointed the high-rate S-band used for core system commanding, telemetry, and voice in an intense effort to maintain communications with the crew, while Ku-band communications for payload data, operations plans, and video were lost. The entire event cost one day of on-orbit operations. No viable work around could be found that would preclude this problem from recurring, so the GPS/INS units were left unpowered for several months to protect the vehicle.. During the time that the units were unpowered, a modification to the GNC flight code was developed and implemented that allowed the U.S. GNC flight computer to continue to function when the Not-A-Number was received. After the ISS GNC flight code was modified, normal operation of the GPS/INS units was resumed. The root cause of the Not-A-Number output from the GPS attitude code was never determined; however, all the attitude code that could have generated it has been re-written. No new occurrences of the Not-A-Number have been noted with the new software. C. Numerous Power Cycles The original attitude determination code exhibited the unfortunate tendency to reset itself under certain circumstances. This behavior was not seen in ground testing, or in any of the Shuttle flight experiments. When a reset occurs, certain parameters are cleared from memory and need re-initialization. This problem was fairly easy to work around, although flight controllers had to perform many more power cycles of the units than was originally envisioned. Typically two to three power cycles per week were being performed due to this particular problem. Another problem was found in the SP code that also required a power cycle to clear. The SP code would set a particular bit called a SubSystem Flag that is part of the MIL-STD 1553B protocol. The setting of this bit is intended to warn the user of the data to disregard the data in the message. This bit was setting every 2-3 months and the GPS/INS unit could only be recovered via a power cycle. The root cause of the setting of the bit was never definitively determined, although the vendor was able to determine a most probable cause. The code that was determined to be the most likely cause was removed. The new software in operation in the ISS GPS/INS units has not seen a recurrence of this problem. Although performing numerous power cycles doesn’t appear at first glance to be of much concern, the GPS/INS units were not qualified to a certain number of power cycles and it was unknown what effect, if any, the numerous power cycles would have on the life of the units. The numerous power cycles also increased the operator work load.

Original page 15

The new software has dramatically decreased the number of power cycles from several times per week to once every 3-4 months. D. Low Position and Attitude Coverage The integer resolution scheme in the original NASA GPS attitude code was a search method designed for use in aircraft carrier phase tracking, as described in reference 16. This method requires an initial attitude estimate, which implies operational constraints. For many of the ISS maneuvers, it is not worth the time required to reinitialize the GPS receiver with an attitude estimate. Also, since the attitude input has to be an aviation legacy East- North-Up reference frame, the attitude update would have to be constantly updated to function properly when the ISS is flying in an inertial hold . Instead, for certain maneuvers, it was accepted that the GPS would not be outputting attitude solutions. For the inertial attitudes, the attitude estimate was input as the attitude of the ISS at one particular moment during the orbit. However, for the rest of the orbit, any attitudes that were output were incorrect since the attitude estimate was incorrect. This search method required that all interrupts be stopped during the search time, meaning that no position, velocity, or time messages (previously discussed) were output from the attitude code at these times. Fig. 8 Attitude Fig. 9 Attitude error in degrees for orbit simulation with ISS multipath environment – new GPS attitude error in degrees firmware. for orbit simulation with ISS multipath environment – original GPS attitude firmware. Since the integer resolution scheme mentioned above was not well suited for ISS, the attitude code was reformulated using a new integer resolution method as part of the re-code effort. This new method simply accumulates measurements over a user defined interval and performs a batch solution for the attitude and the 17 integers. The new method assumes that the ISS is in either an inertial hold or a Local Vertical Local Horizontal (LVLH) hold, which are the only types of attitudes the ISS flies. Figures 8 and 9 show the attitude error during a 12 hour LVLH simulation, for the old and new attitude algorithm with the simulated multipath environment of the ISS (note that the axis scales are different). The coverage statistics for the original and new attitude algorithm for a four day simulation in which the ISS was placed in an inertial hold are shown in Table 2. The simulation includes the blockage of the ISS structure. Coverage is defined as the percentage of time that a fresh attitude or position solution is output. Notice the higher position and attitude coverage for the new method. The increased position coverage is due to the new integer resolution algorithm not obstructing data from being output.

Original page 16

Table 2 Coverage Statistics Comparison Original Method New Method Position Attitude 23% 48% 15% 31% Unlike the original attitude determination firmware, the new firmware does not require an initial attitude estimate. The new firmware has more coverage and better standard deviation statistics. The standard deviation of the error is 26 degrees root mean square for the original method and 4 degrees root mean square for the new firmware. E. Navigation Problems There were also problems encountered with the GPS navigation solution passed by the SP code to the ISS GNC computer. These were traced to various root causes, but the symptom was very similar in each case. Position and velocity solutions slowly diverge from the true state. The ISS error checking tends to accept the diverging solutions as valid since the GPS receiver output slowly drifted from the true state, rather than outputting a single anomalous Drift of position and velocity solution solution. Figure 10 shows an example of such a drift in semi-major axis. Semi-major axis combines the position and velocity outputs into a single number. For ISS, the estimated semi-major axis, when compensated for J2, is a fairly constant number. The drifts were traced to several sources. One was the receiver tracking Fig. 10 Semi-major axis for May 11, 2002. satellites through the Earth’s atmosphere, which caused severe distortion of the pseudorange measurement. Another factor was the health message, which was output in a separate message from the navigation solution. It was occasionally being incorrectly associated with the previous navigation solution rather than the current navigation solution. The new firmware was modified to not track satellites more than 10 degrees below the local horizon to avoid tracking satellites through the Earth’s atmosphere. It was also modified to associate health messages with the proper navigation solution. F. Velocity Noise Due To Ionospheric Scintillation

Original page 17

A. Velocity Noise Due To Ionospheric Scintillation Fig. 11 GPS/INS velocity noise as compared to ground filter. Velocity noise has also been observed in ISS GPS measurements. Reference 18 contains an analysis of both ISS and Shuttle measurements that show this phenomenon. It appears to be related to high ionospheric activity. Figure 11 shows the GPS/INS unit’s velocity noise as compared to a GPS ground filter, called the Spacecraft Position Optimal Tracking (SPOT) filter. Fig. 12 Latitude and longitude for noisy GPS/INS velocity output. Figure 12 shows the latitude and longitude of the GPS solution when the velocity was output with an error that exceeded 0.5 meters/second. These noisy outputs appeared to be clustered in similar patterns as described in reference 19 for ionospheric scintillation. There have been no firmware modifications made to attempt to alleviate the effects of the ionospheric scintillation. The ground filter and onorbit ISS navigation firmware are able to filter these noisy outputs without any adverse system effects. B. Multipath Interference Caused by the Robotic Arm Early in the development of the GPS/INS, it was recognized that multipath signal interference would Fig. 13 Measured differential carrier phase errors compared to GTD predicted differential carrier phase errors for SV24 and antennas 1 and 2 from STS-77 data. 30 meas err 1 20 GTD 1 10 0 Millimeters -10 -20 8 8.05 8.1 8.15 8.2 8.25 8.3 8.35 Hours

Original page 18

Diffraction code compared well to the measured results and that code was therefore selected to be used to predict the ISS multipath environment. Figure 13 shows the comparison between predicted and measured differential carrier phase errors for the STS-77 GPS data. The predicted environment was used as an input in the GPS simulations. The GPS simulation results were then used as input in a simulation to determine whether the ISS attitude filter could meet the 0.5 degree requirement. The results from that analysis indicated that U.S. GNC could meet the requirement. Comparison of the on-orbit U.S. filtered attitude solution to the Russian star tracker data indicate that the U.S. segment does meet the 0.5 degree requirement under the multipath conditions that were analyzed pre-flight. However, a previously unanalyzed situation did cause the U.S. segment to be unable to meet its attitude performance requirements. Figure 14 shows the position where the Space Station Remote Manipulator System (SSRMS or robotic arm) was parked from May 26 - July 22, 2004, for viewing a spacewalk. When the SSRMS is parked over the GPS antenna array, it causes increased multipath and blockage that significantly degrades the GPS/INS performance. There are fewer solutions output and the solutions that are output are much noisier. This is primarily an impact when ISS is flying inertial attitudes, since GPS/INS attitude coverage in these attitudes is already low. From on- Antenna flight software could not remain reliably converged GPS Boresites SSRMS Fig. 14 SSRMS Parked over GPS antenna array. orbit experience, the coverage has been reduced enough that the attitude filters within the U.S. GNC using the attitude data from GPS/INS. While the obvious solution appears to be to avoid parking the SSRMS near the GPS antenna array, it is often operationally impossible to do so. The complexity of activating and physically moving the SSRMS requires several hours of crew time, which is a carefully managed commodity. This results in the SSRMS often being parked over the array for weeks at a time. When the array is parked in the antenna’s field of view, flight controllers reconfigure the ISS GNC software to utilize attitude data from the Russian Segment GNC system, which is available to the U.S. GNC flight software as a backup to GPS. H. GPS/INS Impacts on Mission Control State Vector Ground Processing Although there were no requirements on the GPS/INS to support state vector ground processing, once GPS/INS was operational on ISS, the benefits of such a filter became apparent. Although the position and velocity accuracy requirements for GPS/INS are sufficient to support antenna pointing for TDRS communications, they are not sufficient to support maneuver planning, or long-term orbital prediction and debris avoidance activities performed by Mission Control. A Mission Control based Kalman filter that processes the GPS data on the ground was developed to provide more precise orbit determination using high fidelity environment modeling. A serious challenge faced by filter developers was lengthy GPS/INS state vector outages during integer resolution for attitude determination by the GPS attitude code, which lengthened the time required for the filter to converge on a solution. Numerous telemetry problems also affected data quality. Extensive analysis of GPS/INS data and lengthy development of filter data pre-processor code was required to overcome GPS/INS and ISS telemetry deficiencies. The new firmware, with its new integer resolution scheme, does not have these long outages. I. Impacts of Poor State Vector Coverage Following Reboost ISS reboosts are performed several times a year to counter atmospheric decay and to support phasing

Original page 19

requirements for Shuttle, Soyuz, and Progress vehicle rendezvous. In order to perform a reboost, attitude control of the vehicle is handed over from U.S. segment CMG control to Russian segment thruster control, and the Russian segment performs the reboost itself, normally by utilizing axial thrusters on a disposable Progress resupply vehicle docked to the rear port of ISS. Because there are currently no inertial measurement units in either the U.S. or Russian GNC systems, reboosts are performed with no direct measurement of acceleration. Onboard state vectors in the U.S. system are continuously updated through the burn by applying ground predicted accelerations and (when available) GPS state vectors. The accuracy of the onboard state vector after the burn must remain within 60 kilometers of truth in order to accurately point the ISS Ku-band communications system. Experience has shown performance variability in Russian reboost burns. For example, a reboost on Februrary 11, 2003, was targeted for 6.0 meters/second, but problems with the Progress propulsion system resulted in an actual burn that was later calculated to be 4.1 meters/second. At the time, both Russian and U.S. flight controllers were aware that there had been a problem with the Progress, but were unable to establish the exact post-burnout state vector of ISS because of the lack of sensed acceleration data, poor state vector coverage from the GPS (due to the attitude code not outputting data since the post-burnout attitude was an inertial hold), and the time delay required to process ground radar data. The onboard state vector (which was updated with accelerations assuming a nominal predicted 6.0 meter/second burn) eventually achieved an error of 165 kilometers before enough GPS and tracking data had been taken to establish the actual orbit of the vehicle and true reboost magnitude, nearly 10 hours after burn completion. Following this event, flight controllers modified the reboost sequence to fly a higher GPS/INS performance LVLH attitude for up to an orbit following reboost to increase the likelihood of acquiring post reboost state vectors. Flight controllers also began using accelerometers within the ISS payload system to provide an estimate of reboost performance. Unfortunately, these accelerometers were originally designed to monitor microgravity performance, not core system GNC performance, and are not always available to flight controllers in real time. Additionally, modifications have been made to GPS/INS firmware and U.S. GNC flight software to incorporate the currently unused inertial data from the GPS/INS into the U.S. GNC system by the end of 2006. IV. Lessons Learned The factors that contributed to the delivery of a GPS receiver for use on ISS that requires extensive operator intervention to function and extensive re-development and re-certification are discussed. A. Impacts of the COTS Philosophy The GPS/INS was procured under the philosophy that buying a product as close as possible to the vendor’s commercial off-the-shelf (COTS) product would be less expensive than procuring a product that was uniquely developed for a particular application. In this case, the cost savings were not realized, and the COTS philosophy contributed to the extensive software problems. The GPS/INS hardware was similar in nature to the COTS hardware, but the software requirements for the space application were very unique. The original software was developed for use in airborne applications, not space applications. The modifications required for space application were made without removing or changing the functionality of the code that was uniquely developed for the airborne application. The GPS attitude determination integer resolution technique developed for the airborne application required that the user input roll and pitch, and the software would determine heading. During the time that the software was determining heading, all message outputs would cease. This type of scheme makes sense for an aircraft on a runway that most likely has roll and pitch near zero and an unknown heading, but makes no sense for the ISS application. The ISS either knows its roll, pitch, and heading within 2 degrees or there has been some sort of malfunction. This particular integer resolution scheme, developed for the airborne application, contributed to many of the problems cited in this paper. One of the time problems was traced to the SP code attempting to accommodate the time outages caused by the integer resolution scheme. The poor state vector performance

Original page 20

following re-boosts was traced to the lack of outputs from the GPS receiver caused by the integer resolution scheme continually trying to converge on a solution and therefore not outputting any state vector solutions. The new integer resolution scheme that was designed uniquely for ISS does not have these restrictions and does not lead to the problems cited. The problems noted with the state vector output were also traced to software designed for terrestrial applications. One of the causes of the state vector errors was the GPS code’s use of measurements from satellites that were below the local horizon. These signals exhibited significant delays caused by traveling through the Earth’s atmosphere. In a terrestrial application, it is impossible for a GPS receiver to track satellites below the local horizon, but in a space application such as ISS, satellites as low as 24 degrees below the local horizon have been tracked. As explained above, these low satellite signals typically induce more error than signals from satellites at higher elevations. The aforementioned code modification eliminated this problem by not allowing the GPS/INS to track satellites lower than 10 degree below the local horizontal. The COTS philosophy also dictated that NASA have limited insight into the vendor’s software since the development of the COTS software was not paid for by NASA and is considered proprietary. Even the software developed by NASA could not be obtained by the procuring NASA organization until after the development was complete. To mitigate the risk associated with having limited insight into the software, NASA chose to test extensively. The extensive testing did uncover many anomalies pre-flight, but many were only uncovered after the units were activated on ISS. One could argue that testing should have uncovered all of the anomalies; however, some surfaced after almost one year of continuous operations. It is extremely difficult to design enough tests to uncover those types of anomalies. The original code design was inherently flawed, and no amount of testing could fix the flaws in the time design or the attitude algorithms developed for airborne applications. Rather, the design needed to be tailored for the particular application. B. Requirements Changes Requirements for the GPS/INS common navigator were not well defined at the start of the program, most notably the CRV requirements. As new system requirements were determined, the changes resulted in new software requirements during the development. Even after the GPS/INS was operational on the ISS, new ways of utilizing the data from the GPS/INS were being defined, such as attempting to use the inertial sensor data for reboost application. Additionally, the ISS has flown in different attitudes than were originally envisioned. These attitudes were not tested prior to the delivery of the product. One of the new attitudes was flown during the STS- 114 mission in July 2005. This new attitude protected the Space Shuttle Orbiter from orbital debris by placing the orbiter behind the bulk of the ISS so that the ISS would protect the Orbiter’s tiles. Although the GPS/INS requirements were not written to include this attitude, the new software was able to track satellites and produce valid solutions in this new configuration. Although ideally all requirements would be known completely at the time of procurement, realistically this is rarely the case. The contract type should be chosen to readily accommodate requirements changes. C. Firm, Fixed Price Contract Was Not Appropriate for This Procurement Relatively early in the development it was realized that the vendor was not going to be able to deliver the GPS/INS product for their firm, fixed price bid. Unforeseen requirement changes arose, which inevitably led to schedule and software development problems. In retrospect, this is easy to understand: an attitude determination GPS receiver integrated with an INS product had never been demonstrated in a space environment; therefore, its final development faced a significant degree of uncertainty and risk. The COTS hardware resulted in minimal impact but the software customized for space caused most of the uncertainty. Additionally, the extent of the modifications required to make the COTS product perform in the space environment were not clearly understood by the vendor when the firm, fixed price bid was made. Consequently, using a firm, fixed price contracting mechanism resulted in an inflexible contracting arrangement when technical problems and other unforeseen difficulties arose.

Original page 21

D. Inadequate Software Quality Processes Purchasing COTS products when the vendor (which includes NASA in this case since NASA was a vendor as well as the customer) and NASA do not have adequate hardware and software processes in place can lead to significant operational problems. Both the vendor for the integrated product and the GPS receiver manufacturer had processes in place to ensure the quality of their hardware, and, as a result, the GPS/INS hardware has not had any problems. The navigation code was developed using a recognized coding standard to ensure the quality of the code. The SP code was developed using the vendor’s internal code standards for Department Of Defense applications during the ISS/CRV GPS/INS development. However, NASA did not follow any coding standards during the original development of the attitude determination software. As a result, the navigation code has had relatively few problems compared to the SP code and the attitude determination code. When the SP code was re-written, large portions of unused code were removed. When the attitude code was re-written, it was re-written using an accepted coding standard. The number of anomalies recorded for the upgraded software is less than twelve. The number of anomalies recorded for the original firmware is greater than 200. E. Unrealistic Schedules The original philosophy behind COTS procurements was that the development costs had already been absorbed and the item’s adaptation for use in space would be both faster and cheaper. Unfortunately, in the case of the space software development, this was not a good assumption and it led to very optimistic project schedules. Ultimately, unrealistically optimistic schedules only lead to poor quality software that will probably still be delivered late. The original ISS/CRV GPS/INS development schedule allowed six months for the delivery of the development units. The hardware arrived about one month late, but the software was not completed for another two years, after which it was tested, flown, and then extensively re-written due to its flaws. Although it was suspected that the project schedules were optimistic, there were two reasons to think the schedules could have been met: 1) GPS attitude determination had been demonstrated on flight experiments and 2) the GPS/INS was as close to the vendor’s COTS product as possible (the hardware changes were accomplished with minimal effort and few problems). However, it requires a significant amount of time and effort to take software technology from flight experiment demonstration to the robustness required for a manned spacecraft. Additionally, even though a product appears to work for an existing application, it is imprudent to assume that it is robust or will work well in a different environment. The unrealistic schedule impacted the quality of the software product because rather than create a realistic schedule that included time to create a well-planned software design, time to put in place coding standards, and time for testing of the custom software, the vendors worked long hours until they ultimately produced a system that functioned only marginally and was not robust. F. Ownership When dealing with multi-component boxes that must be integrated into a complex system, the ownership and responsibility for each component must be established early on. The integration of the software and hardware elements should be tested and verified to firm requirements at the unit level by the responsible parties. The flow of the requirements to each developmental item must be established and defined in early stages of the program and should not change if possible. V. Conclusion Implementing GPS on ISS required that many technical and contractual hurdles be overcome. The technical problems included software anomalies as well as physical phenomena that were not well understood, along with

Original page 22

the often conflicting requirements that emerge with development of a device for multiple users. The concept of cost savings by using the same box on multiple vehicles was not realized, and actually led to conflicting requirements that introduced problems for the ISS implementation. The software anomalies were traced to inappropriate use of COTS software, inadequate requirements, and changing system requirements during short development cycles. The contracting problems included an inappropriate contract type and unrealistic schedules. Many of the problems noted here in the development of the ISS GPS/INS are similar in nature and cause to the software induced spacecraft accidents discussed in reference 22, including unrealistic schedules and poor software processes. Acknowledgments Thanks to Mike Lammers of NASA for providing information on the operational impacts of the software anomalies.

Original page 23

References 1 Gomez, Susan F. “Flying High – GPS on International Space Station and Crew Return Vehicle,” GPS World, June 2002. 2 Goodman, J. L., “GPS In Earth Orbit – Experiences From The Space Shuttle, International Space Station And Crew Return Vehicle Programs,” Proceedings of the 2002 Core Technologies for Space Systems Conference, Colorado Springs, CO, November 19-21, 2002. See http://www.spacecoretech.org/, Technology Maturation, Transfer, and Utilization Session. Accessed in July, 2004. 3 Fedora, Neal and Picone, Ron, “The Integratation and Performance of Honeywell’s GPS/INS Navigator with Orbital’s Pegasus Launch Vehicle”, Paper for Digital Avionics Systems Conference, October 2004. 4 Goodman, J. L., “Lessons Learned From Flights of “Off the Shelf” Aviation Navigation Units on the Space Shuttle,” Joint Navigation Conference, Orlando, Florida, May 6-9, 2002. See also Lesson #1370 on the NASA Public Lessons Learned System Database website:http://llis.nasa.gov/llis/plls/index.html. Accessed in July, 2004. 5 Goodman, J. L., “The Space Shuttle and GPS – A Safety-Critical Navigation Upgrade,” COTS-Based Software Systems, edited by H. Erdogmus and T. Weng, Springer-Verlag Lecture Notes in Computer Science Volume 2580, Springer-Verlag, Berlin, Germany, 2003, pp. 92-100. 6 Goodman, J. L., “A Software Perspective On GNSS Receiver Integration and Operation,” Satellite Navigation Systems: Policy, Commercial and Technical Interaction, edited by M. Rycroft, Kluwer Academic Publishers, Dordrecht, The Netherlands, 2003, pp. 119-126. 7 Goodman, John L., “A GPS Receiver Upgrade For The Space Shuttle – Rationale And Considerations,” Paper AIAA-2004- 3911, 40th AIAA/ASME/SAE/ASEE Joint Propulsion Conference and Exhibit, Fort Lauderdale, FL, July 11-14, 2004. 8 Ward L. M., Axelrad P., “Spacecraft Attitude Estimation Using GPS: Methodology and Results for RADCAL,” ION National Technical Meeting, Anaheim CA, January 1995. 9 Axelrad P., Ward L. M., “GPS Attitude Determination Performance for REX II,” CTASS-S513-002 Final Report, April 1995. 10 Lightsey E. G., et al., “Flight Results of GPS Based Attitude Determination on the REX II Spacecraft,” ION GPS-96, Kansas City MO, September 1996. 11 Carpenter, J. R., and Hain, R. M., “Precise Evaluation of Orbital GPS Attitude Determination on the STS-77 GPS Attitude and Navigation Experiment (GANE),” Proceedings of the ION National Technical Meeting, Inst. of Navigation, Fairfax, VA, 1997, pp. 387–398. 12 Brock, J. K., Fuller, R., Kemper, B., Mlezcko, D., Rodden, J., and Tadros, A., “GPS Attitude Determination and Navigation Flight Experiment,” Proceeding of the ION GPS, Inst. of Navigation, Fairfax, VA, 1995, pp. 545–554. 13 Axelrad, Penina, “Post-Processed Attitude and Baseline Estimation for the GPS Attitude and Navigation Experiment (GANE),” Proceedings of the 53rd Annual Meeting of the Institute of Navigation, Albuquerque, NM, June 30-July 2, 1997. 14 Um, Jaeyong, and E. Glenn Lightsey, “Space Flight Test Results for the SOAR Experiment,” Proceedings of ION GPS 2000, Salt Lake City, UT, September 19-22, 2000. 15 Um, Jaeyong, and E. Glenn Lightsey, “GPS Attitude Determination for the SOAR Experiment,” Navigation: Journal of the Institute of Navigation, Volume 48, Number 3, Fall 2001, pages 181-194. 16 Knight, Don, “Method and Apparatus for Maximum Likelihood Estimation Direct Integer Search in Differential Carrier Phase Attitude Determination Systems,” U.S. Patent Number 5,296,861 issued March 22, 1994. 17 Gomez, Susan, F. “New GPS Attitude Algorithms for Use in International Space Station (ISS) Space Integrated Global Positioning System/Inertial Navigation System (GPS/INS),” August 2004.

Original page 24

18 Kramer, Leonard, and John L. Goodman, “Ionospheric Instability Observed in Low Earth Orbit Using GPS,” AIAA Journal of Spacecraft and Rockets, AIAA, Reston, VA, to be published. 19 Knight, Mark Frederick, “Ionospheric Scintillation Effects on Global Positioning System Receivers,” Doctoral Thesis submitted to The University Of Adelaide, December 2000. 20 James R. Pendergrass, Alfred J. Treder and Susan F. Gomez, “GPS-Updated Attitude Determination on ISS Despite Rich Multipath,” AIAA Paper 2000-4469, Proceedings of the AIAA Guidance, Navigation and Control Conference, Denver, CO, August 14-17, 2000. 21 Gomez, Susan F. et al, “Evaluation of Two Computational Techniques of Calculating Multipath Using Global Position System Carrier Phase Measurements,” NASA Technical Memorandum 104816, April 1996. 22 Leveson, Nancy, “Role of Software in Spacecraft Accidents,” Journal of Spacecraft and Rockets, Vol. 41, No. 4, July–August 2004.