REG NASA-LLIS-1370-2002 Lessons Learned Lessons Learned From Flights of Off the Shelf Aviation Navigation Units on the Space Shuttle GPS.pdf

《REG NASA-LLIS-1370-2002 Lessons Learned Lessons Learned From Flights of Off the Shelf Aviation Navigation Units on the Space Shuttle GPS.pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-1370-2002 Lessons Learned Lessons Learned From Flights of Off the Shelf Aviation Navigation Units on the Space Shuttle GPS.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 1370Lesson Info:a71 Lesson Number: 1370a71 Lesson Date: 2002-06-11a71 Submitting Organization: JSCa71 Submitted by: John L. GoodmanSubject: Lessons Learned From Flights of ?Off the Shelf? Aviation Navigation Units on the Space Shuttle, GPS Abstract: Over the last 9 years, the

2、Shuttle program has flown Global Positioning System (GPS) receivers and Space Integrated GPS/Inertial Navigation System (SIGI) units. The NASA Johnson Space Center paper “Lessons Learned From Flights of “Off the Shelf” Aviation Navigation Units on the Space Shuttle“ contains numerous recommendations

3、 that constitute the body of this lesson.Description of Driving Event: The Space Shuttle program began flying atmospheric flight navigation units in 1993, in support of Shuttle avionics upgrades. In the early 1990s, it was anticipated that proven in-production navigation units would greatly reduce i

4、ntegration, certification and maintenance costs. However, technical issues arising from ground and flight tests resulted in a slip in the Shuttle GPS certification date. A number of recommendations were developed concerning the adaptation of atmospheric flight navigation units for use in low-Earth o

5、rbit. They are applicable to any use of a navigation unit in an application significantly different from the one for which it was originally designed. Flight experience has shown that atmospheric flight navigation units are not adequate to support anticipated space applications of GPS, such as auton

6、omous operation, rendezvous, formation flying and replacement of ground tracking systems. Space Shuttle Tactical Area Navigation (TACAN) Replacement with GPS In 1990, the Shuttle Program began to investigate the use of GPS, based on the anticipated phase-out of TACAN starting in the year 2000. The S

7、huttle Program desired a receiver that was in mass production and had an existing logistics base. Anti-jam and anti-spoofing capabilities were also desired. A trade study conducted in 1993 chose the five channel Miniaturized Airborne GPS Provided by IHSNot for ResaleNo reproduction or networking per

8、mitted without license from IHS-,-,-Receiver (MAGR), which entered production in 1994. The MAGR/Shuttle, or MAGR/S, was procured as a TACAN replacement and for use as a source of state vectors while on-orbit. There were no requirements for the MAGR/S to be used for applications involving high accura

9、cy orbit determination, such as ground radar and Tracking & Data Relay Satellite (TDRS) tracking replacement or spacecraft rendezvous. The MAGR/S will be certified to serve as a TACAN replacement in both keyed and unkeyed configurations. No requirements were levied on the vendor to change the MAGR/S

10、 Kalman filter, which was designed for use on a variety of aviation platforms without modification. An orbital state vector propagation algorithm was added to support satellite acquisition after a GPS outage. A pre-production MAGR, called the 3M, was flown seven times on the Shuttle Endeavor from De

11、cember 1993 to May 1996. The first flight of a production MAGR missionized for the Shuttle application (MAGR/S) occurred in September of 1996. By the fall of 1997, five test flights of the MAGR/S on the Space Shuttle had occurred. At that time, the Shuttle Program decided to replace the three TACAN

12、units on Atlantis with three MAGR/S units. The first “no TACAN, all GPS“ flight was scheduled for January 1999 (STS-92). By June of 1998, the first flight of Atlantis with three string GPS had changed to STS-96 (May 1999), due to changes in the International Space Station (ISS) assembly schedule. Wh

13、ile on-orbit during STS-91 (Discovery, June 1998), the final Shuttle-Mir mission, a MAGR/S firmware problem and several flaws in the Space Shuttle computer software that communicate with the MAGR/S were discovered. Certification of the MAGR/S was postponed. MAGR/S firmware and Shuttle software issue

14、s were resolved, and additional MAGR/S firmware versions, ground and flight-testing were planned. Certification of the MAGR/S for operational use occured in 2002. However, it is not known when the Shuttle Program will decide to replace the TACAN units with the MAGR/S receivers. With the start of TAC

15、AN phase-out delayed until 2010, it is expected that the Shuttle Orbiters will fly with three TACAN units and one MAGR/S receiver for some time. Three Shuttle flights (STS-81, -84 and -86) carried Embedded GPS/INS (Global Positioning System/Inertial Navigation System), or EGIs, from two different ve

16、ndors to collect data for the X-33 program. In 1996, NASA began a project to eventually replace the MAGR/S receivers and the High Accuracy Inertial Navigation System (HAINS) Inertial Measurement Units (IMUs) with a space-missionized EGI, known as a Space Integrated GPS/INS (SIGI). SIGI was envisione

17、d as a “common NASA navigator“ that could be used on a variety of manned and unmanned vehicles. The Shuttle SIGI flew on seven missions between September of 1997 and December of 1999 for data collection. Since the HAINS IMUs are projected to be operational through 2010, replacement of the HAINS IMUs

18、 and MAGR/S units by SIGIs has been deferred. Lesson(s) Learned: Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-The Shuttle Program selected off-the-shelf GPS and EGI units that met the requirements of the original customers. It was assumed that off

19、-the-shelf units with proven design and performance would reduce acquisition costs and require minimal adaptation and minimal testing. However, the time, budget and resources needed to test and resolve firmware issues exceeded initial projections.Recommendation(s): 1. A Realistic Schedule and Budget

20、 Is Needed. Particular attention should be paid to how realistic the schedule is considering the complexity and technical risk involved. A recent study of NASA projects that used a faster-better-cheaper approach indicated that mission failures resulted from highly complex projects on short developme

21、nt timelines.2. Fixed price contracts should be avoided if development work is required. Such contracts can result in inflated vendor estimates for initial cost and can remove the incentive to aggressively resolve technical issues. Resolution of these issues may not be covered in the budget defined

22、at project start. Technical issues must be addressed early in a project, even in the presence of cost and schedule concerns. These issues can easily become showstoppers later in the integration. Not addressing issues until late in a project will drive up cost and shift schedules to the right. Proble

23、ms arising from cost and schedule slips and failure to address issues can create adversarial relationships between project participants and the vendor. Fixed price contracts are appropriate when the planned use of the unit is the same as the original application for which the unit was designed. In t

24、his case, little or no development work is required. Modifying an aviation navigation unit for use on an unmanned or manned spacecraft should be budgeted and scheduled as a development project. 3. Resources and Schedule Must Be Allocated To Analyze Test Data. When planning a navigation unit missioni

25、zation and integration, adequate time and personnel must be set aside to analyze flight and ground test data. If data is not thoroughly analyzed in a timely manner, firmware issues will go unnoticed. Lack of resources can even lead to failure to analyze test data. Performance issues arising late in

26、the development and certification cycle can negatively impact cost and schedule.4. 5. Maintain an Integrated Team Approach. The “success oriented” nature of project budgets and schedules sometimes result in limited communication at the technical level. Multiple layers of contractors cut down on comm

27、unication and should be avoided. The vendor should be involved in all design reviews. Early MAGR/S project reviews focused on hardware modifications, with little attention paid to firmware. Most technical personnel were “fire walled” from the firmware missionization Provided by IHSNot for ResaleNo r

28、eproduction or networking permitted without license from IHS-,-,-process and the vendor. No formal, program wide reviews of the GPS receiver firmware modifications were made. The GPS vendor and the Shuttle navigation (both operational and engineering, contractor and civil servant) personnel had mini

29、mal involvement in the missionization decisions made by the integrator. The GPS vendor was more fully integrated into the GPS project to enhance communication due to anomalies that surfaced during STS-91. Weekly teleconferences were established that included the vendor and all NASA and contractor or

30、ganizations. Face to face meetings of all project participants were held at the Johnson Space Center three to four times a year. Special teams that crossed civil servant and contractor boundaries were formed to address specific technical problems. The GPS receiver is a critical part of an EGI. Unfor

31、tunately, the user and integrator often have little or no opportunity to interact with the GPS manufacturer on an EGI contract. Contracts concerning EGI units should be written so that the GPS vendor will be involved and able to give advice and information to the EGI manufacturer, the integrator and

32、 the user. 6. Produce, Test and Fly Interim Firmware Versions. Firmware issues tend to be discovered sequentially. Units containing complex firmware may not manifest anomalies in the initial round of ground and flight tests. This can lead to a false sense of security about the maturity of a firmware

33、 version. Enough rigorous ground and flight testing must be planned to thoroughly exercise the firmware. Schedule and budget should include interim firmware versions to allow issues to be discovered and resolved before a production firmware load is scheduled for certification. 7. Keep Accurate Recor

34、ds. Detailed and accurate records of meetings, issues and issue disposition and design rationale should be maintained. This enables project participants to be better informed on issues facing the project and provides a record for the future. An official issue list should be maintained, along with a

35、list of questions for the vendor and vendor responses. 8. A Close Relationship Between The Vendor And Customer Is Needed. Both the MAGR/S and SIGI projects demonstrated the need for a close working relationship between the integrator, users and vendor. The navigation vendor needs to be involved in e

36、arly decisions on architecture and integration. Frequent and open communication between technical personnel should be encouraged. This lesson is best summed up as “communicate early, communicate often.” The “throw a unit and an ICD over the fence” approach can lead to cost and schedule problems. Due

37、 to communication constraints imposed by “success oriented” budgets and schedules, vendors are frequently not involved in the design of software that is to interface with a GPS or EGI unit. In hindsight, some aspects of the Shuttle GPS integration might have been done differently had the vendor been

38、 involved. The Shuttle software that interfaced with the MAGR was designed with an inadequate understanding of the firmware behind the interface Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-definition. This lack of receiver insight was one of the

39、causes of the problems encountered on STS-91. Shuttle software that interfaced with the GPS receiver had to be bullet proofed against known and postulated receiver anomalies. Regular face-to-face contact between the vendor and Shuttle engineers built positive, personal relationships and established

40、a “team” rather than an “adversarial” environment. Communication between other project participants also improved. Both the vendor and Shuttle Program engineers became familiar with each others “work cultures,” which enabled them to work better together and provide appropriate support to each other.

41、 The vendor also provided much needed education to Shuttle engineers concerning the challenges of GPS receiver design and operation. Use of complex, “off the shelf” aviation navigation units in unmanned and manned space applications requires vendor involvement over and above that provided in terrest

42、rial aviation projects. 9. Educate The Vendor About Your Application. The GPS vendor observed Space Shuttle ascents and entries from Mission Control. Vendor GPS engineers also flew landings in a Space Shuttle simulator and were present in the cockpit of the Shuttle Avionics Integration Laboratory wh

43、en MAGR/S testing was performed, and participated in lab tests of the MAGR/S at Shuttle Program facilities. These activities permitted the vendor to ascertain how the Space Shuttle application differed from aviation users of GPS receivers. These experiences were found to be very helpful in understan

44、ding customer concerns and identifying improvements to be made to the receiver. This enabled the vendor to propose solutions to technical issues that were agreeable to the various parties within the project. The vendor became familiar with the strengths and weaknesses of Shuttle Program GPS simulati

45、on facilities. This enabled them to provide input to Shuttle integration engineers concerning how best to perform receiver testing and verify MAGR/S functionality. 10. Talk To Those That Have Used The Product Before. Outside consultants, who do not have a stake in the choice of a particular unit, sh

46、ould be used. Such consultants have “hands on experience” with box integrations and can be an important information source concerning their design, integration and use. Consultants who have participated in previous integrations will have knowledge of problems that other users have encountered. Consu

47、ltants and other users can also provide valuable insight into the rationale and requirements that governed the original design of the unit. This information is invaluable to the integrator for identifying technical, cost and schedule risks associated with a particular navigation unit integration. 11

48、. “Plug And Play” Versus Development. The fact that a unit is in mass production and is a proven product does not mean that its integration into a different vehicle will be a simple, problem free “plug and play” project. A difference in application (such as aviation versus space flight) will result

49、in the manifestation of firmware issues that may not have appeared in the original application. Unique data interfaces used by manned and some unmanned Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-spacecraft avionics may require modification of the unit. Power supply changes and radiation hardening may also have to be performed. 12. Test As Much As You Can. A lack of comprehensive, end-to