Status Report

NASA Report: Overview of the DART Mishap Investigation Results – For Public Release

By SpaceRef Editor
May 15, 2006
Filed under ,
NASA Report: Overview of the DART Mishap Investigation Results – For Public Release
http://images.spaceref.com/news/dart.jpg

On April 15, 2005, the Demonstration of Autonomous Rendezvous Technology (DART) spacecraft was successfully deployed from a Pegasus XL rocket launched from the Western Test Range at Vandenberg Air Force Base, California. DART was designed to rendezvous with and perform a variety of maneuvers in close proximity to the Multiple Paths, Beyond-Line-of-Sight Communications (MUBLCOM) satellite, without assistance (autonomously) from ground personnel.

DART performed as planned during the first eight hours through the launch, early orbit, and rendezvous phases of the mission, accomplishing all objectives up to that time, even though ground operations personnel noticed anomalies with the navigation system. During proximity operations, however, the spacecraft began using much more propellant than expected. Approximately 11 hours into what was supposed to be a 24-hour mission, DART detected that its propellant supply was depleted, and it began a series of maneuvers for departure and retirement. Although it was not known at the time, DART had actually collided with MUBLCOM 3 minutes and 49 seconds before initiating retirement.

Because DART failed to achieve its main mission objectives, NASA declared a “Type A” Mishap, and convened a Mishap Investigation Board (MIB) chaired by Scott Croomes of NASA’s Marshall Space Flight Center. A “Type A” mishap is NASA’s designation for a mishap that has resulted in a NASA mission failure that exceeds a government loss of one million dollars. This mishap category requires the most detailed level of investigation. In DART’s case, none of the 14 requirements related to the proximity operations phase – the critical technology objectives of the mission – were met. However, the other portions of the DART mission, including the launch, early orbit, rendezvous, and departure and retirement phases, were completely successful. Out of a total 27 defined mission objectives, DART fully or partially met 11 of those objectives.

After the collision, both spacecraft remained in orbit. Because of this, no physical spacecraft remains were available for examination; however, other evidence was available for use by the MIB. The MIB investigated the mishap and determined its underlying causes based on hardware testing, telemetry data analysis, and numerous simulations. From its investigation, the MIB developed two timelines: one for DART’s premature retirement and another for DART’s collision with MUBLCOM.

After addressing causes related to both timelines, the MIB developed and documented in a formal report recommendations aimed at avoiding such occurrences in the future. Additional recommendations were added to the report through endorsement letters generated by the Exploration Systems Mission Directorate (ESMD) and the Office of Safety and Mission Assurance (OSMA).

NASA has completed its assessment of the DART MIB report, which included a classification review by the Department of Defense. The report was found to be NASA-sensitive, but unclassified, because it contained information restricted by International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR). As a result, the DART mishap investigation report was deemed not releasable to the public. The following provides an overview of publicly releasable findings and recommendations regarding the DART mishap.

DART PROJECT BACKGROUND

Proposed by Orbital Sciences Corporation (OSC) in response to a 2001 NASA Research Announcement from the 2nd Generation Reusable Launch Vehicle (2GRLV) Program, DART was selected by NASA as a high-risk technology demonstration project. The DART contract was awarded in May 2001 to OSC within a broad NASA Research Announcement (NRA8-30). The proposed cost of the DART mission was 47 million dollars.

Later, in November 2002, the 2GRLV Program was redefined and became two new programs, the Orbital Space Plane (OSP) Program and the Next Generation Launch Technology (NGLT) Program. DART, along with other flight demonstration projects, was transferred to the OSP Program. In the process, increased emphasis was placed on DART, because automated rendezvous technology was considered to be critical in supporting the potential future needs of the International Space Station Program.

In January 2004, after President Bush announced the Vision for Space Exploration to explore the moon, Mars, and beyond, the OSP Program was cancelled. Because of its relevance to the in- space assembly of certain exploration architecture concepts, however, the DART project was continued. Because of the project’s maturity at that time (its original, target launch date was scheduled for 2004), DART became NASA’s first flight demonstration of new exploration capability. The DART mission was eventually launched on April 15, 2005, and cost 110 million dollars.

THE DART AND MUBLCOM SPACECRAFT

The DART spacecraft was a combination of two systems. The forward segment contained DART-specific systems including a propulsion tank, reaction control system thrusters, batteries, communications equipment, and the Advanced Video Guidance Sensor (AVGS). The AVGS, the mission’s primary sensor, would collect navigation data while DART was in close proximity to MUBLCOM. The aft portion of the DART spacecraft was the fourth stage of a Pegasus launch vehicle, and included an avionics assembly and the Hydrazine Auxiliary Propulsion System (HAPS).

The AVGS would gather data from laser signals reflected off targets mounted on MUBLCOM, and use these signals to calculate relative bearing and range data; that is, the direction and distance from DART to MUBLCOM. When the DART-mounted AVGS was within 200-500 meters of MUBLCOM, it was expected to provide only bearing measurements. When the AVGS was within 200 meters of its target, it was expected to provide not only bearing, but also range and relative attitude (orientation of a spacecraft relative to an external reference) data.

Other navigational sensors that were to work in concert with the AVGS included two Global Positioning System (GPS) receivers on DART and a GPS receiver on MUBLCOM. DART would use data from these GPS receivers to determine position and velocity relative to MUBLCOM. Based on an intricate combination of data from all of its navigational sensors, on- board software would guide DART while it was in close proximity to MUBLCOM. DART was not designed to receive commands from the ground, an approach considered philosophically consistent with the objective that DART be a demonstration of autonomous technology.

The MUBLCOM satellite was DART’s rendezvous target. OSC launched MUBLCOM in 1999 for the Defense Advanced Research Projects Agency. Following completion of its original and primary mission, MUBLCOM remained in orbit in good operational condition.

THE DART MISSION PLAN

The intent of DART was to demonstrate that a pre-programmed and unaided spacecraft could independently rendezvous or meet up with a non-maneuvering and cooperating satellite. A series of 27 objectives for a successful mission were developed and divided among four defined mission phases. The four mission phases were as follows: 1) the launch and early orbit phase, 2) the rendezvous phase, 3) the proximity operations phase, and 4) the departure and retirement phase.

Launch and Early Orbit Phase

During the launch phase, the DART spacecraft, coupled with its Pegasus launch vehicle, would be flown to an altitude of 40,000 feet over the Pacific Ocean aboard a carrier aircraft. Following release, the three-stage Pegasus rocket would ignite, carrying DART into an initial parking orbit below MUBLCOM. From there, it would begin a series of navigation system checks, verifying position estimates for both itself and its target, MUBLCOM.

Rendezvous Phase

During the mission’s rendezvous phase, after completing the systems checks, DART would fire its HAPS thrusters to move into a second phasing orbit or rendezvous. The HAPS burn would be timed to specifically position DART below and behind MUBLCOM in preparation for the mission’s next phase.

Among other things, NASA intended to demonstrate that a comparison of position and velocity data from GPS receivers in two spacecraft would be accurate enough to guide the “chaser” spacecraft (DART) to a position within the effective range of a proximity operations navigational sensor such as the AVGS.

Proximity Operations Phase

During the proximity operations phase, a series of scheduled maneuvers would move DART into MUBLCOM’s orbit, first at a position about 3 kilometers behind, and then about 1 kilometer behind the target.

When it was 1 kilometer behind MUBLCOM, DART was programmed to evaluate AVGS performance through a series of precise, close-range maneuvers. These maneuvers included various pre-planned holds (station-keeping periods at designated points in space), a collision- avoidance maneuver at a pre-determined position, and a maneuver to determine at what distance from MUBLCOM the AVGS tracking data could no longer be acquired.

Departure and Retirement Phase

After completing its proximity operations maneuvers, DART would perform a departure burn (to move it away from MUBLCOM), expel its remaining fuel, and place itself into a short-lifetime retirement orbit in compliance with NASA safety standards.

DESCRIPTION OF THE MISHAP

During the actual DART mission, all went as expected throughout the launch and early orbit phases. The vehicle successfully completed its rendezvous phase as well, placing itself into a second staging orbit about 40 kilometers behind and 7.5 kilometers below MUBLCOM, even though ground operators began to notice an irregularity with the navigation system.

When DART began its transfer out of the second staging orbit to begin proximity operations, ground operators observed that the spacecraft was using significantly more fuel than expected for its maneuvers. It became clear that the mission would likely end prematurely because of exhausted fuel reserves. Because DART had no means to receive or execute uplinked commands, the ground crew could not take any action to correct the situation.

During the series of maneuvers designed to evaluate AVGS performance, DART began to transition its navigational data source from the GPS to AVGS as planned. Initially, the AVGS supplied only information about MUBLCOM’s azimuth (angular distance measured horizontally from the sensor boresight to MUBLCOM) and elevation relative to DART. However, as DART approached MUBLCOM, it overshot an important waypoint, or position in space, that would have triggered the final transition to full AVGS capability. Because it missed this critical waypoint and the pre-programmed transition to full AVGS capability did not happen, the AVGS never supplied DART’s navigation system with accurate measurements of the range to MUBLCOM. Consequently, DART was able to steer towards MUBLCOM, but it was not able to accurately determine its distance to MUBLCOM. Although DART’s collision avoidance system eventually activated 1 minute and 23 seconds before the collision, the inaccurate perception of its distance and speed in relation to MUBLCOM prevented DART from taking effective action to avoid a collision.

Less than 11 hours into the mission, DART collided with MUBLCOM. MUBLCOM did not appear to experience significant damage, and the impact actually pushed it into a higher orbit. Then, shortly after the collision, DART determined that it was nearly out of maneuvering fuel, and initiated its pre-programmed departure and retirement maneuver. DART’s departure and retirement phase proceeded per the original plan, and MUBLCOM regained its operational status after an automatic system reset that resulted from the collision.

IDENTIFYING MISHAP CAUSES AND RECOMMENDING SOLUTIONS

NASA’s major goal in performing mishap investigations is to improve safety by identifying the proximate (immediate) and root causes of a mishap, and by providing recommendations that will prevent future occurrences of similar events. It is important to note that if any one of the proximate causes was removed from the chain of events leading up to the mishap, then the mishap would not have occurred. By performing analyses to determine ‘why’ each of the proximate causes occurred, an MIB is able to identify root causes that may be common to other systems. The following summarizes the mishap causes identified by the DART MIB.

Causes of DART’s Premature Retirement

The proximate cause of DART’s premature retirement was that DART used up its maneuvering fuel (pressurized nitrogen gas) before it could complete its objectives. The MIB found that a repeated pattern of excessive thruster firings in response to incorrect navigational data onboard DART caused the higher than expected fuel usage. Ultimately, DART spent too much fuel as it continuously carried out corrective maneuvers while steering itself towards MUBLCOM, thus causing a premature end to the mission.

Normally, a spacecraft’s software-based navigational system operates by constantly estimating its position and speed, and comparing these estimates with measurements from its navigational sensors. If the estimate and the measured position are in agreement, then the software can issue the correct commands to the maneuvering thrusters in order to effectively guide the spacecraft along its desired flight path.

In DART’s case, the MIB determined that the first cause for its premature retirement occurred when the estimated and measured positions differed to such a degree that the software executed a computational “reset.” By design, this reset caused DART to discard its estimated position and speed and restart those estimates using measurements from the primary GPS receiver.

Careful examination of the software code revealed that upon reset, the velocity measurement from the primary GPS receiver was introduced back into the software’s calculations of the spacecraft’s estimated position and speed. If the measured velocity had been sufficiently accurate, the calculations would have converged and resulted in correct navigational solutions. However, DART’s primary GPS receiver consistently produced a measured velocity that was offset or “biased” about 0.6 meters per second from what it should have been. This had the unfortunate effect of causing the calculations, which were being performed autonomously, to once again diverge until the difference became unacceptable to the pre-programmed computer logic. Once the limit as to how much the calculations could differ was reached, the software executed another reset. As a result, this cycle of diverging calculations followed by a software reset occurred about once every three minutes throughout the mission. These continual resets caused the incorrect navigational data that prompted excessive thruster firings and the higher than expected fuel usage.

The reason an incorrect velocity measurement from the primary GPS receiver was introduced into the software’s calculations during a reset was because the software fix for this known “bug” had never been implemented by the DART team. In addition, the software model that simulated the receiver during preflight testing assumed that the receiver measured velocity perfectly. However, even with the incorrect velocity data being introduced into the calculations at each reset, the MIB determined that the navigational software’s design was also inadequate. The design requirements stated that the measured velocity data only had to be accurate to within 2 meters per second (positive or negative). In reality, the design was incapable of accommodating a measured velocity with that much error, and the actual, erroneous data from the primary GPS receiver was off by less than 1 meter per second.

Yet even that deficiency was not enough to cause the continual calculation divergences and resets. An additional feature in the computational logic known as “gain” controlled how much the calculations were based on the estimated position and speed versus the measured position and speed. The gain determined how much “weighting” the two types of data (estimates versus measurements) received in the final calculations of differences.

The MIB concluded that the gain was set at an inappropriate level such that the calculations could never converge once the initial reset happened. The pre-programmed gain setting, which was changed late in the spacecraft’s development, caused the logic to “trust” the estimated data more than it reasonably should have. This change did not undergo proper testing and simulations to verify the effects of the weighting. During analysis of pre-flight test data following the mishap, the MIB demonstrated that with the original (higher) gain setting, the string of repeated diverging calculations and software resets would have been broken.

In summary, the persistent, inaccurate, navigational information that caused DART’s premature retirement resulted from a combination of: 1) an initial, unacceptable, calculated difference between DART’s estimated and measured position that triggered a software reset; 2) the introduction of an uncorrected, erroneous velocity measurement into the calculation scheme; 3) a navigational software design that was overly-sensitive to erroneous data; and 4) the use of incorrect gain control in the calculation scheme.

Contributing to the premature retirement mishap was the nature of the design approach used for DART’s guidance system. To make corrections to its flight path, DART’s guidance system used continual, course-correcting thruster firings rather than using a limited number of specific, mid- course correction maneuvers. DART’s guidance system was not as capable as the second guidance approach; the second approach could have handled divergent navigation estimates more effectively. While DART’s guidance approach contributed to the mishap, it did not directly cause it to occur.

Additionally, the MIB found that the on-board computer logic that determined the remaining amount of maneuvering fuel during the mission significantly over-estimated the usage rate. This factor caused DART to declare that the fuel was at its lower limit when, in fact, about 30% of the fuel was still in the tank. The MIB’s analysis showed that this much fuel, had it been available for use, would have allowed the mission to continue for some minutes, but not long enough to complete the mission objectives, given the navigational problems (even if the collision had not occurred).

Causes of DART’s Collision with MUBLCOM

The collision with MUBLCOM was caused by the inaccurate navigation system performance as described above coupled with increasingly accurate azimuth and elevation information from the AVGS. This had the effect of lining MUBLCOM up in the “cross hairs” of DART’s guidance system at a time when the system did not have the ability to accurately control the distance between the two spacecraft. This condition existed because DART’s pre-programmed logic for switching to AVGS distance measuring capability required the spacecraft to fly into an undersized, imaginary sphere (waypoint) along the flight path 200 meters behind MUBLCOM. The MIB’s analysis of the telemetry data from the flight shows that DART missed this 6.3 meter radius spherical envelope by less than 2 meters. The reasons for this inadequately-designed logic include the unanticipated potential for navigational errors and a lack of adequate design review.

When DART missed the critical waypoint for switching to full AVGS capability, it continued moving toward MUBLCOM. DART’s design included a means of collision avoidance, but its capability proved to be ineffective. The software logic for collision avoidance was dependent on the same navigational data source as the guidance system. The impact of this dependency was that DART’s calculated position and speed did not match its actual position and speed. In fact, at the time of collision, DART was flying toward MUBLCOM at 1.5 meters per second while its navigational system thought it was 130 meters away from MUBLCOM and retreating at 0.3 meters per second. The collision avoidance design approach never anticipated the possibility that the navigational data would be this inaccurate.

SUMMARY OF ROOT CAUSES AND RECOMMENDATIONS

DART was a one-time project. Because of this, the MIB did not propose specific design changes for the DART spacecraft. The formal mishap report contains detailed recommendations for the root causes that should prevent similar mishaps in the future. The following summarizes root causes and recommendations formally addressed by the MIB.

High Risk, Low Budget Nature of the Procurement

DART was selected by NASA as a high-risk, low-budget technology demonstration under a NASA Research Announcement (NRA). The government procured only the data, and set broad requirements. Most of the detailed design decisions about how to meet those requirements were left to the discretion of the contractor.

In DART’s case, OSC carried over many of DART’s design features from the Pegasus launch vehicle approach. For example, the software architecture, which consisted primarily of a pre-programmed, timed sequence of fixed commands, worked adequately for a launch vehicle, but as was eventually found by the MIB, was not able to respond adaptively while performing autonomous in-space operations with unanticipated inputs.

The MIB recommended that the NRA acquisition approach be used for procuring only the initial conceptual design for technically-complex, high-priority flight missions. Further, it was recommended that the subsequent mission spacecraft design, development, and operations contracts use government-controlled, detailed specifications, and provide for a greater degree of control over key design decisions.

NASA Headquarters, in its review of the MIB report, disagreed with this MIB finding. The ESMD endorsement letter noted that, “the NRA is a viable procurement instrument for future flight experiments if there is appropriate peer review of the concept(s) and appropriate management rigor.”

Training and Experience

In the case of DART, a lack of training and experience led the design team to reject expert advice because of the perceived risks involved in implementing the recommendations. In turn, this led to inadequate navigation system design and testing.

The DART MIB recommended that NASA centers with technical responsibility for rendezvous operations obtain an independent assessment of their capabilities. Center management should develop recruitment, retention, and training goals to fill any skill gaps. Finally, in NASA’s source selection process, the training and experience of contractor teams should be evaluated.

Despite its problems, the MIB noted the value of conducting such a mission as DART. The “hands on” experience gained from actual flight system design and operation is crucial to overcoming knowledge deficiencies in autonomous spacecraft rendezvous techniques.

Lessons Learned Analysis

Even though the DART team lacked training and experience, many of DART’s inadequacies could have been addressed through review and proper application of mission experience and data (lessons learned) documented from previous NASA projects.

The MIB recommended revising NASA’s engineering peer review procedures to require an independent check of how the project team has analyzed and acted upon “lessons learned” from previous missions.

Guidance, Navigation and Control (GN&C) Software Development Process

The MIB determined that one of the root causes of the mishap was an inadequate GN&C software development process. Changes to the flight code and simulation models were often incorporated without adequate documentation. In one case in particular, a change to the navigation system’s reset logic was made that introduced the use of GPS velocity (as measured from the primary GPS receiver) as the new, estimated DART velocity whenever a reset occurred. This then, became the only instance in which this particular parameter was to be accepted directly into the navigation system’s logic.

Most of the DART team was unaware that the GPS velocity output was to be used in this way by the navigation system’s software. Because this was thought to be an “unused” parameter, personnel responsible for testing the receiver’s performance and those using the mathematical models of the components never realized the need to correct the problem with the biased velocity measurement or include the bias in the receiver’s simulation model. Because of this, the velocity output of the receiver hardware and that of the simulated receiver did not match. As a result, the pre-flight simulations failed to reveal the adverse effect of the inaccurate velocity measurement from the primary GPS receiver as seen during the mission.

In another case, an omitted units conversion caused an error in a simulation math model. This error was discovered after most “hardware-in-loop” system testing had been completed. The late discovery of this error was due to the inadequate GN&C software development process.

In response to its findings, the MIB recommended revising NASA policy to clarify that simulations and math models used to validate flight software must be verified and validated to the same rigorous level as the flight software itself. In addition, NASA software design standards should be revised to prevent unused parameters resident in the code from adversely affecting the flight software performance.

Systems Engineering

For the DART mishap, the MIB determined that there was an inadequate, system-level integration process, which failed to reveal a number of design issues contributing to the mishap. In some cases, there was insufficient system-level understanding of the potential effects of complete or partial loss of functionality of relevant subsystems. Performance requirements for critical capabilities, such as collision avoidance, were not detailed enough to preclude numerous possible design interpretations, not all of which would lead to a system that worked correctly.

The MIB recommended that NASA continue development of a NASA procedural requirements document for systems engineers, as well as require certification of systems engineers. Project and program managers should also be required to have extensive experience and training in systems engineering.

OSMA’s MIB endorsement letter states, “The MIB report clearly indicated that inadequate systems engineering (including a lack of implementation of software requirements, configuration control, validation of math models and testing) was a significant causal factor in the mishap. The report demonstrates that this was a failure to implement existing (NASA) engineering requirements, standards and practices.” Consequently, it further recommended that the Office of the Chief Engineer consider performing independent audits or reviews of NASA program and project compliance with NASA systems engineering requirements, currently under development, as a supplement.

Schedule Pressure

Schedule pressure was identified as the cause for the inadequate testing of a late change to the navigation logic’s gain setting. Correction of the units conversion error in the simulation math model described earlier led to a lowering of the gains setting to improve the expected proximity operations performance based on mission simulations. However, because the gain change happened so close to the planned launch, it was never adequately tested. The MIB determined that the pressure to maintain a scheduled launch was the root cause for the decision to forego testing of the change using the flight hardware and software. Adequate testing after the change would have revealed the problem with the lowered gain setting.

As a result of this finding, the MIB recommended establishing a set of checks and balances to ensure that technical discipline is maintained throughout the entire development process, up to and including the launch and operations phase. Flight projects should develop and be able to report upon measures of flight readiness. Program or project plans for high-priority flight missions should require management checks to ensure that safeguards are in place against launching an improperly or incompletely-verified vehicle configuration.

International Traffic in Arms Regulations (ITAR) Restrictions

In the case of DART, the MIB concluded that insufficient technical communication between the project and an international vendor due to perceived restrictions in export control regulations did not allow for adequate insight.

In order to better facilitate critical data exchange in key mission areas, the MIB recommended revising NASA policy to require program and project managers to confer with export control officials in order to evaluate the adequacy of data exchange arrangements. Likewise, detailed export control training should be required for project personnel involved in interactions with foreign entities.

Technical Surveillance/Insight

The MIB determined that in several instances, the NASA DART insight team failed to identify issues that led to the mishap because of an inadequate assessment of project technical risk and insufficiently-defined areas of responsibility. For example, examination of raw test data and performance of independent tests of some flight components by the government insight team were defined by NASA project management to be “out-of-scope.”

Because of this, the MIB recommended revising NASA policy to require a thorough risk assessment for high-priority flight missions, so that the necessary level of government technical surveillance on contract performance can be established. Project plans should clearly define appropriate levels of insight resulting from the risk assessment.

Risk Posture Management

A rigorous assessment and decision process for managing risk includes ongoing evaluation of NASA’s priorities. In DART’s case, the lack of adequate risk management contributed to a zero- fault tolerant design and inadequate testing that resulted in an insufficient collision avoidance system, among other things. Historically, NASA clearly understood and accepted that DART began as a low-cost, high-risk demonstration. As DART’s significance changed, and it gradually became a highly visible milestone for NASA’s high-profile exploration vision, NASA’s tolerance for a possible mission failure decreased substantially.

Because of this, the MIB recommended requiring program and project management committees to regularly review each project’s risk level classification in light of changing conditions to ensure continued consistency with the potentially shifting risk tolerance for that project. Decisions to maintain or change a project’s classification should be clearly documented.

Expert Utilization

The MIB noted cases where the DART team failed to fully use the resources of available subject matter experts. Both the insight and peer review processes provide mechanisms for ensuring that adequate technical expertise is supplied to the project.

The MIB recommended revising NASA policy to clarify that complex, high-priority flight missions be required to use the engineering peer review process. Likewise, the project team should be required to formally address and document its use of the peer reviewers’ findings and recommendations.

Contractor Review Processes

The MIB concluded that internal checks and balances used by DART’s prime contractor failed to uncover issues that led to the mishap, such as the undersized spherical envelope surrounding the AVGS range transition waypoint.

To address this, it recommended that NASA clearly communicate to the contractor its expectations of entrance and exit criteria for standard design and development reviews for high- priority flight projects. Projects should demonstrate the appropriate management rigor in assessing readiness to proceed to the subsequent phase of development.

Failure Modes and Effects Analysis (FMEA)

The MIB determined that analyses to identify possible hardware/software faults failed to consider a sufficient set of conditions that could lead to the mishap. For example, the analyses focused on the effects of a complete loss of functionality of the navigation system’s components, but did not address the impact of a degraded functionality of those same components.

The MIB recommended that degraded functionality be considered in future analyses, and that those analyses be subject to engineering peer review. In addition, NASA should define the minimum fault tolerance required for spacecraft performing rendezvous missions in order to protect space assets from collision. Future spacecraft that include autonomous rendezvous, proximity operations, and capture systems should have a collision avoidance sensing capability that is completely independent of the spacecraft’s primary navigation sensors. Furthermore, designers for such spacecraft should develop and adhere to a robust, detailed set of requirements for fault detection, isolation, and recovery in order to prevent a mishap.

OSMA’s endorsement letter states that, “The MIB repeatedly discussed how some of the heritage Pegasus software was used on the DART mission and contributed to the mishap. (This was documented in the report as an intermediate cause to a few contributing factors); however, the MIB’s recommendations do not adequately address this.” The endorsement letter further states that, “If NASA decides to adopt heritage code, in the future, we (NASA) need to verify that it is appropriate for the mission and fully test it.”

CONCLUSION

In response to the Vision for Space Exploration to the Moon, Mars and beyond, NASA has entered a new and exciting period in its history where exploration is a primary objective. Autonomous spacecraft rendezvous, proximity operations, and capture capabilities will continue to be critically important to successful space exploration. As the DART project evolved, its planned mission clearly supported that vision. While DART’s transition to such a high-visibility and important project did not proceed as planned, the lessons learned from the mishap will help enable the future development of autonomous capabilities.

SpaceRef staff editor.