Overview of the DART Mishap Investigation Results 

For Public Release 

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. 

1
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 inspace 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, onboard 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. 

2
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 collisionavoidance 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 

3
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 

4
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 

5
continual, course-correcting thruster firings rather than using a limited number of specific, midcourse 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 pre6
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

7
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 

8
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 zerofault 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. 

9
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 highpriority 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. 

10