From Data Collection to Lessons Learned

Space Failure Information Exploitation at The Aerospace Corporation

Jonathan F. Binkley, Paul G. Cheng, Patrick L. Smith, and William F.
Tosney

The Aerospace Corporation

Los Angeles, CA 90009

######### Abstract

The Aerospace Corporation extracts lessons learned from launch vehicle
and satellite anomalies to help the space community avoid repetition of
mis­haps. Incorporated in reports to industry, program reviews, and
journal publications, the lessons lend themselves to influence new
acquisition guide­lines and military specifications. Government and the
commercial space communities, which share a common interest in quality
improvement, should work together to es­tablish more comprehensive and
effective approaches to developing and disseminating lessons learned.

######## A "One Strike You're Out" Environment

*"Space is unforgiving; thousands of good decisions can be undone by a
single engineering flaw or work­manship error, and these flaws and errors
can result in catastrophe,"* observed the Defense Science Board (Defense
Science Board 2003). Indeed, despite many years of experience, so many
accidents still occur (Frost and Sullivan 2004) that insurance rates for
commercial satellites approach 25% (Aviation Week 2003, Aviation Week
2005).

Consequently insights from past anomalies are of considerable interest
to many stakeholders. Acqui­sition policy makers, design engineers, risk
assessment specialists, and quality assurance managers seek answers to
many questions: What types of compo­nents are the most trouble-prone?
What is the cost/benefit ratio of redundancy? What is an acceptable
tradeoff between newer technology and manufacturing maturity? Which
environmental tests are the most percep­tive? Why do satellites fail
despite extensive verification efforts?

######## The Aerospace Corporation's Space System Engineering Database 

The Aerospace Corporation operates a Federally Funded Re­search and
Development Center for the United States Air Force, provid­ing objective
assessments for National Security Space (NSS) pro­grams. The Corporation
is directly accountable for many oversight functions necessary to ensure
NSS mission success. Prior to any launch, Aerospace provides a letter to
its NSS customer confirm­ing the mission's readiness as concluded by a
rigorous assessment that draws upon the collective expertise of a cadre
of engineers with expertise in a wide variety of disciplines. Aerospace
has applied this process to several hundred launches, reducing risks (as
compared with commercial launch programs for the first three flights)
tenfold.

  -----------------------------------------------------------------------
  To assist the Air Force and its other customers in the conception,
  design, acquisition, and operation of space systems, The Aerospace
  Corpora­tion began developing the Space Systems Engineering Database
  (SSED) in 1992 to acquire and manage vali­dated technical information,
  primarily on NSS systems and programs (Tosney 1992, Tosney 1993).
  Figure 1 shows the SSED architecture.[^1]

  ![](media/image1.wmf){width="5.258333333333334in"
  height="4.652083333333334in"}

  Figure 1. Architectures of the SSED and Salient Features of its Anomaly
  Domain
  -----------------------------------------------------------------------

######## Anomaly Data Collection 

The SSED archives anomaly and discrepancy reports, primarily from NSS
programs, including in­forma­tion on over 20,000 launch vehicle and
satellite anomalies that occurred in the factory, at the launch site,
during flight, or in operation. Most of these anomalies are routine test
and operational problems. System-level satellite tests, for example,
typically generate dozens of discrepancy reports; even successful
launches are marred by scores of anomalous telemetry readings. Major
anomalies result in exhaus­tive investigations, many of which are
thoroughly documented in the SSED.

The SSED contains less information on anomalies occurring on civil,
commercial, and foreign pro­grams. Thorough reports of commercial U.S.
launch failures are usually available to The Aerospace Corporation
because the same launchers are used by NSS programs. Many reports of
NASA satellite failure reports are also available. The Aerospace
Corporation has even found a few Japanese and Russian failure
investi­gation reports and had them translated into English. However,
compared to the air transport industry, the space community is
tight-lipped about failures: Root causes of failures---even the presence
of defects---in commercial satellites are routinely not disclosed (Space
News 2005). The SSED's collection of anomaly information is there­fore
far from complete.

######## Anomaly Data Archiving and Retrieval

The anomaly information in the SSED is organized in a relational
database that allows cross-program re­trieval and analysis of anomalies
by unit, subsystem, contractor, and many other categories in­cluding the
severity and impact on the mission. Supporting anomaly documentation
from contractors and failure in­vestigations is digitized and annotated
with extensive metadata. Over 100,000 docu­ments of various types have
been archived; all can be searched via a web interface.

The SSED anomaly data has supported a wide variety of studies (Arnheim
2005, Tosney 1997, Tosney 2001a, Tosney 2001b, Wendler 2003, White
2002). Here's a hypothetical example showing how the SSED enables
component engineers to bore into causes of individual anomalies: An
engi­neer was asked to investigate a Program X reaction wheel that showed
signs of impending failure. A database search for "Program X + reaction
wheels + anomaly + lubrication" found 18 Program X-specific documents,
primarily design packages, test information, and operational reports.
With some analysis the engineer determined that the wheel's performance
appeared to be "in-family" for this block of satellites. The engineer
also performed a broader search, finding 153 similar documents from
other programs. Based on this information, the engineer was able to
estimate the likelihood that a second wheel might fail should the first
wheel in fact malfunction prematurely.

######## Post-Flight Anomaly Analysis

Engineers at The Aerospace Corporation carefully analyze all off-nominal
reports from NSS pro­grams, seeking to identify engineering errors,
workmanship escapes, model deficiencies, test inadequacies, de­fective
parts, hostile environments, or other factors that may warrant
correction.

For example, all off-nominal telemetry readings from a launch program
are logged in the SSED. A technical expert is assigned to account for
each anomaly and the reasons why it occurred. Every anomaly
investigation is tracked by the program office as part of Aerospace's
flight-readiness verifi­cation responsibilities. Fault-management
lessons, reliability impacts, and suggested corrective actions are
documented. Fortunately, all operational launches from this program have
been success­ful thus far, bucking the high odds of infant mortalities.

This rigorous "post-flight analysis" tracking procedure is prompted by
the expensive lesson from, among others, Defense Support Program (DSP)
F-19 which was stranded in the wrong orbit (U. S. Air Force 1999)
because the Inertial Upper Stage (IUS) technicians wrapped insulating
tape too close to a connector, preventing stage separation.[^2]
Afterwards, engineers re­viewing the telemetry from previous IUS flights
realized that the connector was jammed *every time*. In fact, seven of
the previ­ous flights dodged failure only because the taped connectors
were jerked apart when they hit the allowable stops---the flight just
before DSP-19 had the narrowest escape. Unfortunately, the warning signs
in the telemetry data were not heeded.

######## Why Do Satellites Fail? 

+-----------------------------------------------------------------------+
| ***"It's always the simple stuff that kills you........It's not that  |
| they are stupid, with all the testing systems everything looked       |
| good." James Cantrell, Main Engineer for the Skipper Mission***       |
|                                                                       |
| *Skipper failed because its solar panels were connected backwards     |
| (Associated Press 1996).*                                             |
+-----------------------------------------------------------------------+

Table 1 summarizes the causes of recent U.S. Government satellite
failures. Evidently, satellite mis­haps are primarily due to preventable
engineering mistakes, instead of poor work­manship, defective parts, or
an unexpectedly hostile environment. On the other hand, launches
typically fail due to pro­duction and workmanship defects, though five
out of six U.S. unmanned launches failures since 1999 also occurred as a
result of engineering errors.

These failure statistics highlight the challenge faced by the
verification and review efforts that pre­cede each mission: Flight items
can only be checked and verified against *known* requirements. But
engineering mistakes occur in endless, subtle ways: an overlooked or
poorly worded requirement, a unit mix-up, or even a typo. Besides saying
that robustness and quality must be "designed in," how else can one
guard against subtle mistakes?

Table 1. U.S. Government Satellite Failures (1990--2002) [^3]

+----+-------+--------------------------------------+--------+--------+
| #  | *     | **Cause**                            | *      | **Tech |
| Da | *Prog |                                      | *Engin | nology |
| te | ram** |                                      | eering | Surp   |
|    |       |                                      | Mis    | rise** |
|    |       |                                      | take** |        |
+====+=======+======================================+========+========+
| 0  | H     | A defect in the optical corrector    | x      |        |
| 4/ | ubble | used in manufacturing and in QA      |        |        |
| 90 |       | misshaped the mirror                 |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | TSS-1 | Mechanism jammed by a bolt added     | x      |        |
| 7/ |       | after I&T                            |        |        |
| 92 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | Mars  | Corroded braze jammed a regulator,   | x      | x      |
| 9/ | Obs   | causing an overpressure that         |        |        |
| 92 | erver | breached the propul­sion line---parts |        |        |
|    |       | not qualified for long duration      |        |        |
|    |       | mission/braze not on the vendor      |        |        |
|    |       | materials list                       |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | NOAA  | Charger shorted by a long screw due  | x      |        |
| 8/ | 13    | to low dimensional tolerance and     |        |        |
| 93 |       | stress imparted by added instrument  |        |        |
+----+-------+--------------------------------------+--------+--------+
| 1  | La    | Pyrovalve explosion                  |        | x      |
| 0/ | ndsat |                                      |        |        |
| 93 | F     |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | Cleme | CPU froze, depleting fuel - fault    | x      | x      |
| 1/ | ntine | management ineffective               |        |        |
| 94 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | MSTI  | Micro­meteor­oid/debris impact or      |        | x      |
| 5/ | 2     | charging                             |        |        |
| 94 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 1  | Sk    | Solar array miswired/Test did not    | x      |        |
| 2/ | ipper | ascertain current direction          |        |        |
| 95 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | T     | Contamination inside the tether      | x      |        |
| 2/ | SS-1R | caused arcing                        |        |        |
| 96 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | Lewis | Power loss---flawed GN&C             | x      |        |
| 8/ |       | design/inadequate monitoring         |        |        |
| 97 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 1  | S     | Satellite/launcher resonance caused  | x      |        |
| 0/ | TEP-4 | vibration damage                     |        |        |
| 97 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 1  | STEX  | Solar array fatigued---analysis run  | x      |        |
| 0/ |       | on wrong con­figuration               |        |        |
| 98 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 1  | MCO   | Burned up due to unit                | x      |        |
| 2/ |       | mix-up/vulnerable navigation         |        |        |
| 98 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | MPL   | Requirement flowdown error shut      | x      |        |
| 1/ |       | engine down pre­maturely              |        |        |
| 99 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | WIRE  | Unexpected logic chip start-up       | x      | x      |
| 3/ |       | transient prematurely fired pyros;   |        |        |
| 99 |       | inhibit circuit design was flawed    |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | Simp  | Transmitter arcing                   |        | x      |
| 8/ | lesat |                                      |        |        |
| 01 |       |                                      |        |        |
+----+-------+--------------------------------------+--------+--------+
| 0  | CO    | Structural failure caused by         | x      |        |
| 7/ | NTOUR | excessive heating during SRM         |        |        |
| 02 |       | firing---Plume analysis used to      |        |        |
|    |       | qualify design by similarity was     |        |        |
|    |       | misled by a typo in an AIAA paper    |        |        |
+----+-------+--------------------------------------+--------+--------+

######## Benefits of Learning Lessons

+-----------------------------------------------------------------------+
| ######## *"Fools say that they learn by ex                            |
| perience, I prefer to profit by others\' experience." Otto Bismarck*  |
+-----------------------------------------------------------------------+

Smart engineers learn from failures. Consider the Clementine spacecraft.
Equipped with an inade­quate central processor, Clementine's on-board
computer encountered a series of glitches, all handled without
difficulty---until a numeric overflow occurred just at the point when
the computer had begun firing the thrusters. A "watchdog timer"
algorithm, designed to stop the thrusters from continuously firing,
could not execute since the computer had crashed. The fuel was depleted;
the mission ended.

Engineers on the Near Earth Asteroid Rendezvous (NEAR) mission grasped a
key insight from the Clementine failure: the watchdog func­tion should be
*hard-wired* in case the computer shuts down. As it happened, NEAR later
suffered a computer crash similar to Clementine's. For the next 27
hours, until the computer could be rebooted, NEAR's thrusters fired
thousands of times, but each firing lasted only a fraction of a second
before being cut off by the still-operative watchdog timer. NEAR
survived (NASA 1999, Lee 2004).

######## Hurdles to Lesson Learning

To facilitate lesson learning NASA set up an extensive, publicly
accessible, lessons learned database. Yet a General Accounting Office
(GAO) audit report recently concluded that the NASA initiative has not
been effective (GAO 2002). A primary impediment was a reluctance to
share failure experiences, the consequence of which can be illustrated
by an incident with the Orion rocket: Someone forgot to install a
voltage-reduction component into the test meter used to check the
motor's circuit continuity. As a result the rocket accidentally ignited
on its horizontal test stand in 1993, killing a Swedish range
technician. When details of this accident were eventually made public,
spokespersons for two other facilities revealed that they also had
inadvertently ignited rockets with the same meter (Casey 2004)!

Busy engineers often neglect to research lessons on past projects. The
Wide-Field Infrared Explorer (WIRE) mission failed due to an
unanticipated start-up quirk of a logic controller. Although the
con­trol­ler start-up behavior was described in the device's Data Book and
NASA's "Application Notes," neither the designers nor the vendor's field
engineer knew about the problem. "\[We need\] an infor­mation hotline,
set up on an industry-wide lessons learned web page," WIRE engineers
said later (Gibbons 1999).

Even when a lesson is widely known throughout the industry, it may still
be overlooked. A Maxus rocket crashed in 1991 because spent hydraulic
fluid, which drained at the nozzle exit plane, caught fire. The flame,
which was recirculated by external air flow into the aft area, damaged
an uninsulated guidance cable, causing the vehicle to veer off course.
This incident was widely reported and caused several programs to
redesign the fluid drains away from the plume or to add cable
insulation. How­ever, one program did not---despite using a very similar
thruster vector control system---and its maiden flight subsequently
suffered the same type of failure.

######## Lessons Learned Program: "Driver's Education" for Space Engineers

The Aerospace Corporation has published a series of "Space Systems
Engineering Lessons Learned," following the GAO's "storytelling"
guidelines and focusing on three questions:

1.  Why did the mistake occur? (Usually, some improper engineering
    practices.)

2.  What prevented its detection? (The verification approach was likely
    flawed.)

3.  How was the flaw able to bring down the entire system? (The fault
    management or redundancy design was probably inadequate.)

Each lesson uses the after-action report to highlight key en­gineering
practices that should have been followed. Thus far, 100 lessons, based
on 79 catastrophic failures, 32 major anomalies (such as loss of an
instrument), 21 ground problems (such as test damage) and three mission
recoveries, have been published and distributed to industry (Cheng
2002). An example is shown below.

+--------------------------+-------------------------------------------+
| ***[A Sample             |                                           |
| Lesson]{.underline}***   |                                           |
|                          |                                           |
| *A satellite's bus       |                                           |
| provides power to the    |                                           |
| primary receiver (Rx A)  |                                           |
| via a fuse* () *and to   |                                           |
| the back-up via a        |                                           |
| circuit breaker* ()*.    |                                           |
| The receiver power was,  |                                           |
| via an "OR" diode* (*,   |                                           |
| i.e., permit­ting the     |                                           |
| down­stream cir­cuits to   |                                           |
| draw current from either |                                           |
| receiver), tapped off by |                                           |
| two transmitter          |                                           |
| (Tx)/antenna switches*   |                                           |
| () *and two commercial   |                                           |
| grade status indicator   |                                           |
| relays* () *com­manded by |                                           |
| the flight computer*     |                                           |
| ()*. The system          |                                           |
| re­quirements stated that |                                           |
| status indicator relays  |                                           |
| should re­ceive pulsed    |                                           |
| commands.*               |                                           |
+--------------------------+-------------------------------------------+
| ![                       | *Software documents did not pick up this  |
| ](media/image2.wmf){widt | specification, and a con­stant voltage was |
| h="2.3715277777777777in" | supplied instead. Unit test overlooked    |
| height                   | the mistake be­cause the test set soft­ware |
| ="1.8715277777777777in"} | correctly drove the relays with pulsed    |
|                          | signals. System test should have caught   |
|                          | the error because the con­tinu­ously        |
|                          | powered coils drew five extra watts, a    |
|                          | considerable amount in a low-power        |
|                          | sys­tem. Unfortunately, the extra power    |
|                          | draw was not noticed.*                    |
|                          |                                           |
|                          | *Thought as not crucial and thus not      |
|                          | space qualified, the relays shorted under |
|                          | continuous heating, tripping the circuit  |
|                          | breaker and disabling Re­ceiver B.         |
|                          | Receiver A, supposedly isolated, also     |
|                          | blew the fuse because it was tied to the  |
|                          | short via the "OR" diode. The mis­sion     |
|                          | ended.*                                   |
+--------------------------+-------------------------------------------+
| *Several lessons can be  |                                           |
| drawn from this          |                                           |
| incident, including:*    |                                           |
|                          |                                           |
| -   *Ensure that the     |                                           |
|     architecture         |                                           |
|     isolates faults      |                                           |
|     (isolation resistors |                                           |
|     or down­stream fuses  |                                           |
|     could have prevent   |                                           |
|     the system           |                                           |
|     collapse).*          |                                           |
|                          |                                           |
| -   *Create a            |                                           |
|     verification matrix  |                                           |
|     and make sure        |                                           |
|     requirements are     |                                           |
|     correctly            |                                           |
|     implemented (the     |                                           |
|     flight software did  |                                           |
|     not met the system   |                                           |
|     require­ments).*      |                                           |
|                          |                                           |
| -   *Incorporate flight  |                                           |
|     software into test   |                                           |
|     at the earliest      |                                           |
|     opportunity.*        |                                           |
|                          |                                           |
| -   *Inspect all test    |                                           |
|     data for trends and  |                                           |
|     "out-of-family"      |                                           |
|     values, even when    |                                           |
|     all values are       |                                           |
|     within expectation.  |                                           |
|     Seek to explain all  |                                           |
|     anoma­lous data.*     |                                           |
|                          |                                           |
| -   *Check for shorting  |                                           |
|     and commercial part  |                                           |
|     usage in failure     |                                           |
|     analysis.*           |                                           |
+--------------------------+-------------------------------------------+

Additional examples include:

-   A computer would not boot up in space because low-temperature
    turn-on drew much larger current than steady-state operation. The
    current limiter, adapted from another mission, was undersized, and
    the failure signature during ground tests was not noticed. Lesson:
    Check start-up behaviors at low temperatures, including
    fault-tolerance circuits.

-   An instrument's power supply malfunctioned in space. The problem was
    not caught because the test set supplied backup power. Lesson:
    Independently confirm performance for functions tempo­rarily provided
    by test sets.

-   A payload was damaged during thermal vacuum testing because the test
    cable, which was not space-qualified, induced multipaction
    breakdown. Lesson: Equipment used in simulated space environments
    must be space-rated.

-   A launch failed because during ground software change, part of the
    code was inadvertently left out. Lesson: Change control processes
    for software, including ground software, require the same degree of
    rigor as the original development.

-   The reset window of a computer's start-up watchdog timer was set too
    short, and the processor could not boot up in space. Lesson: Provide
    a back-up start mode lest a single parameter error cause infinite
    looping (for example, after several unsuccessful attempts, the
    spacecraft should be able to switch to an emergency start mode
    requiring less system resources but permitting ground intervention).

######## 100 Questions for Technical Review 

Failure reports routinely lament "inadequate reviewing." How can
reviewers, in a few hours, find a mistake that has escaped years of
design and quality checks by the contractor and program office?

To help reviewers check that designers have not repeated past mistakes,
the prescriptive lessons have been recast as "100 Questions for
Technical Review," (Cheng 2005) which are open-ended and must be
tailored to particular situations by reviewers based on their expertise.
A reviewer earns his pay if just one of these questions gets the
response: "You know, we hadn't thought about that, we better check it!"

Here are some examples:

-   Are units and tolerances specified? (This question is based on an
    incident where a vehicle was damaged because the ground support
    equipment used a wrong flow rate. Coordination and re­views did not
    catch the mistake because the requirement only mentioned a "desired"
    rate.)

-   Have all "heritage equipment" test and flight anomalies been
    resolved? (On several launches a valve stuck open, and the trouble
    was disregarded because it was survivable. The valve stuck closed in
    the next launch and the rocket veered off course.)

-   Have all critical analyses been placed under configuration control?
    (Two launches failed because air entered the turbopumps, where it
    froze and jammed the turbines. The original analysis showing that
    air could not come in was invalidated by design changes.)

-   Has the fault-protection system been independently verified? (A
    phantom problem spoofed a launcher's fault-management logic,
    terminating a flight.)

-   How are database parameters verified? (A launch failed because a
    parameter, manually entered into the avionics database, had a
    misplaced decimal point.)

-   Are handover procedures between two sources of control well defined?
    (A rocket blew up when ground- and airplane-based command signals
    contended for control, confus­ing the self-destruct unit.)

-   Are drawing tolerances compatible with manufacturing processes? (A
    satellite was lost due to a short caused by tolerance stack-up.)

-   Have designs been analytically established before testing? (The
    magnetic torque rods on a satel­lite were set during test instead of
    being determined by analysis. Unfortunately the test engineer did
    not realize the Earth's Magnetic North pole is in Antarctica and
    consequently set the phasing wrong. The spacecraft tumbled after
    deployment.)

######## The Way Ahead

The Aerospace Corporation has prototyped the task of collecting anomaly
information and extracting lessons, as described in this paper, as part
of its mission assurance responsibilities to its National Security Space
customers. To make even greater progress toward improving space system
reliability will require cooperation of the space communities.

It is currently difficult to conduct comprehen­sive cross-program
reliability studies and derive experi­ence-based reliability estimates
for common space hardware (such as batteries, thrusters, and star
trackers), similar to methods used in the nuclear and chemical process
industry because detailed de­sign and manufacturing information currently
reside in stovepiped contractor databases. To address this challenge,
the customers have expressed interest in a system that will task each
System Program Office to not only manage and validate their mission
assurance data, but also transfer this informa­tion to the SSED system
for use across the NSS enterprise.

The Aerospace Corporation has proposed an anomaly reporting format along
with a series of stan­dards for associated configuration data (Davis
2005). Aerospace is also working on a pilot program toward a
centralized, comprehensive database of satellite design, pedigree and
anomaly informa­tion---a database that contains complete as-built parts
lists for all satellites that will, for example, enable potentially
defective parts to be quickly and thoroughly identified. Tracking the
development and testing history for every major satellite component will
allow later anomalies to be correlated to specific manu­facturing and
testing shortfalls. Data sharing agreements are being developed to allow
this information to be centralized, with appropriate protection of
contractors' proprietary information.

Working with the NSS customers, The Aerospace Corporation is also
striving to improve its lessons dissemination process, most importantly
by di­rectly incorporating them, with sufficient technical depth, into
engineering standards, mission assurance handbooks, testing guidelines,
and military specifications. Each new specifi­cation or standard should
be referenced to actual failure histories and lessons learned, to ensure
that designers understand *why* the specification or standard is being
prom­ulgated. We hope that this initiative will create a closed-loop
learning process that will help avert future mistakes.

######## Concluding Remarks

The Aerospace Corporation collects space system anomaly information,
feeding back lessons learned into programs' design, review,
verification, and acquisition processes. Web, database and document
search technologies are being harnessed to improve access to this
information. Still, proprietary and stove-piped information barriers
remain serious impediments to community-wide information shar­ing and
lesson learning. Government and the commercial space communities must
work together to establish more com­prehensive and effective approaches
toward developing and disseminating lessons learned.

######## 

  -----------------------------------------------------------------------
  ***"It has been said that the only thing we learn from history is that
  we do not learn. But surely we can learn if we have the will to do so."
  Chief Justice Earl Warren***

  -----------------------------------------------------------------------

######## 

######## References

Arnheim, B., Peterson, A., and Wright, C. 2005. "Development of the
Ad­vanced Environmental Test Thoroughness Index--A Work in Progress," in
*Proceedings of the 22nd Aerospace Testing Seminar*, Manhattan Beach,
CA, March 2005.

Associated Press. 1996. "Wiring Blunder Doomed Satellite." Washington D.
C.: McGraw-Hill. March 20, 1996.

Aviation Week & Space Technology. 2003. "Aon Space Expands." Washington
D. C.: McGraw-Hill. June 23, 2003.

Aviation Week & Space Technology. 2005. "Satellite Operators, Insurers
Fear Impact of Unfavor­able Conditions," April 25, 2005.

Casey, S. 2004 "*Disaster By Design.*" available on-line at
[http://www.hql.or.jp/gpd/eng/www/nwl/ n12/design.html]{.underline}.
Accessed July 29, 2005.

Chang, I. 1996. "In­vestigation of Space Launch Vehicle Catastrophic
Failures," *J. of Spacecraft and Rockets*, 33, 198-205.

Cheng, P., Chism, D., Giblin, M., Good­man, W., Smith, P., and Tosney, W.
2002. "Space Systems Engineering Lessons Learned System," in
*Proceedings of the SatMax 2002 Conference: Satellite Performance
Workshop*, Arlington, Virginia, April 2002. AIAA-2002-1804.

Cheng, P. 2005. "100 Questions for Technical Review." Aerospace Report
TOR-2005(8617)-4204 available to the U.S. Government agencies and
contractors from the library of The Aerospace Cor­poration, (310)
336-5110.

Davis, D. and Tosney, W. 2005. "An Overview of National Security Space
System Development Test Standards," in *Proceedings of the 22nd
Aerospace Testing Seminar*, Manhattan Beach, CA, March 2005.

Defense Science Board. 2003. "Report of the Defense Science Board/Air
Force Scientific Advisory Board Joint Task Force on Acquisition of
National Security Space Programs." [http://www.acq. osd.mil/dsb/
reports/space.pdf]{.underline}. Accessed July 29, 2005.

Euler, E, Jolly, S., and Curtis, H. 2001. "The Failures of the Mars
Climate Orbiter and Mars Polar Lander---A Perspective from the People
Involved" in *Guidance and Control 2001; Proceedings of the Annual AAS
Rocky Mountain Conference*, Breckenridge, CO, January 2001. pp. 635-655.

Frost & Sullivan Corporation. 2004. "Commercial Communications Satellite
Bus Reliability Analy­sis, August 2004"
[http://www.satelliteonthenet.co.uk/white/frost3.html]{.underline},
Accessed July 29, 2005.

GAO 2002. "NASA: Better Mechanisms Needed for Sharing Lessons Learned,"
GAO-02-195, [http:// www.gao. gov/new.items/d02195.pdf]{.underline}.
Accessed July 29, 2005.

Gibbons, W. and Ames, H, 1999. "Use of FPGAs in Critical Space Flight
Applications---A Hard Lesson," in Proceedings of the 1999 MAPLD
International Conference, available on-line at [http://
klabs.org/richcontent/MAPLDCon99/Papers/B1_Gibbons-Ames_P.doc]{.underline}.
September 2001. Accessed July 29, 2005.

Lee, S. 2004. "NEAR Rendez­vous Burn Anomaly," in "Aerospace Mishaps and
Lessons Learned Seminar," 2004 MAPLD International Conference,
Washington, D.C., September 2004, available on-line at
[http://klabs.org/
mapld04/tutori­als/mishaps/presentations/6_near_sue_lee.ppt]{.underline}.
Accessed July 29, 2005.

Messidoro, P., Bader, M., Brunner, O., Cerrato, A., and Anello, G. 2005.
"Recent Mat€D Lessons Learned on Test Perceptiveness and Effectiveness,"
in *Proceedings of the 22nd Aerospace Testing Seminar*, Manhattan Beach,
CA, March 2005.

NASA 1999. "The NEAR Rendezvous Burn Anomaly of December 1998, Final
Report of the NEAR Anomaly Review Board, November 1999," available
on-line at [http://klabs.org/richcontent/ Reports/Failure\_
Reports/NEAR_Rendezvous_Burn.pdf]{.underline}. Accessed July 29, 2005.

Newman, J. 2001. "Failure-Space, A Systems Engi­neering Look at 50 Space
System Failures," *Acta Astronautica*, 48, 517-527.

Space News 2005. "Telesat to Withhold Incentive Awards for Slow
Reporting of Satellite Problems," Springfield, VA; Imaginova. April 18,
2005.

Sperber, R. 2002. "Hazardous Subsystems," in *Proceedings of the SatMax
2002 Conference: Satellite Performance Workshop*, Arlington, Virginia,
April 2002. AIAA-2002-1803.

Tosney, W. and Chiu, R. 1992. "A Space Systems Pedigree Database
Program," in *Proceedings of the 1992 Institute of Environmental
Sciences Annual Technical Meeting*, Nashville, TN, May 1992.

Tosney, W. and West, B. 1993. "Space System Test Database Design
Concept," in *Proceedings of the 14th Aerospace Testing Seminar*,
Manhattan Beach, CA, March 1993.

Tosney, W. and Quintero, A. 1997. "Orbital Ex­perience from an
Integration and Test Perspective," in *Proceedings of the 17th Aerospace
Testing Seminar*. Manhattan Beach, CA, October 1997.

Tosney, W. 2001a. "Knowledge Management Strategies for Space Program
Develop­ment, Integra­tion and Test," in *Proceedings of the 4th
International Symposium on Environmental Testing for Space Programs*,
Liege. Belgium, June 2001

Tosney, W., Clark, J., and Arnheim, B. L. 2001b. "The Influ­ence of
Development and Test on Mis­sion Success," in *Proceedings of the 4th
International Symposium on Environmental Testing for Space Programs,*
Liege. Belgium, June 2001.

U. S. Air Force. 1999. "Launch Vehicle Broad Area Review," 1999.
[http://klabs.org/richcontent/
Reports/Failure_Reports/Space_Launch_Vehicles_Broad_Area_Review.
pdf]{.underline}. Accessed July 29, 2005.

Wendler, B. 2003. "Establishing Minimum Environmental Test Standards for
Space Vehicles," in *Proceedings of the 21st Aerospace Testing Seminar*,
Manhattan Beach. CA, October 2003.

White, J., Arnheim, B., and King, E. 2002. "Space Vehicle Life Trends,"
in *Proceedings of the 20th Aerospace Testing Seminar*, Manhattan Beach,
CA, March 2002.

[^1]: ^^ Other organizations have established databases similar to the
    SSED. For the European counterpart of the SSED, see (Messidoro
    2005).

[^2]: ^^ The thermal tape on the connector plug housing should be
    wrapped to leave enough clearance so the harness could disengage.
    Assembly instructions stated that the tape shall be applied
    "*within* 0.5 inches of the mounting bracket flange" (instead of,
    for example, "*no closer than* 0.5 inches and no farther than 1.0
    inch"). Unaware that the parts had to unfasten and thinking that the
    they should wrap the tapes as tightly as possible, the technicians
    applied the tapes so close to the flange that the separator jammed.

    ![](media/image3.wmf){width="5.924305555555556in"
    height="1.8576388888888888in"}

[^3]: ^^ For tabulation of space-related failures, see (Chang 1996,
    Newman 2001, Spreber 2002). For first-hand failure discussions, see
    (Euler 2001, Gibbons 1999). Additional on-line resources are
    available from the NASA-associated Klabs, http://www.klabs.org/ and
    the private Satellite News Digest web, http://www.sat-index.com/.
    Root causes of non-government satellite failures are often either
    unknown or not published due to proprietary concerns.