The System Approach to Successful Space Mission Development€¦ · The System Approach to Successful Space Mission Development Eric J. Hoffman and Glen H. Fountain onceptualizing

E. J. HOFFMAN AND G. H. FOUNTAIN

C

The System Approach to Successful Space MissionDevelopment

Eric J. Hoffman and Glen H. Fountain

onceptualizing and executing space missions calls for creative thinking coupledwith careful and conservative implementation. The engineers and scientists who designsuch missions must master a “wide dynamic range” of techniques, from brainstormingto design reviews. Operating in space has never been easy, and the “better, faster,cheaper” mandate imposed by today’s overconstrained budgets has created newcomplications. This article presents the Laboratory’s philosophy for meeting thesechallenges. (Keywords: Space history, Space mission design, Spacecraft design, Systemengineering.)

INTRODUCTIONThe APL Space Department has designed, built, and

launched 58 spacecraft.1 Another is in the final stagesof integration and test, approaching launch, and threemore are in early development. Three of our space-craft—the Delta series—were developed jointly withanother organization (McDonnell-Douglas), and onewas integrated on a standard bus purchased from Or-bital Sciences (the Far Ultraviolet Spectroscopic Ex-plorer [FUSE]). APL spacecraft have ranged from the53-kg environmental research satellite 5E-3 to the2720-kg Midcourse Space Experiment (MSX), a 14-instrument “observatory class” spacecraft comparablein the scope of its instrumentation to the Hubble SpaceTelescope. APL helped pioneer quick-reaction space-craft (a record possibly being the 75-days-to-launchTransit Research and Attitude Control [TRAAC]),invented many widely used spacecraft techniques, anddeveloped entire space systems, such as the Navy

482 JOH

Navigation System (Transit). Several important sys-tems have been transferred to industry for productionafter being conceived and developed at APL, includ-ing Transit, the Global Positioning System Package(GPSPAC), and Geosat. More recently, APL has ex-tended its “better, faster, cheaper” methodologies tolow-cost interplanetary missions such as the Near EarthAsteroid Rendezvous (NEAR), Advanced Composi-tion Explorer (ACE), Comet Nucleus Tour (CON-TOUR), and MESSENGER.

In the course of all this activity, APL acquired areputation for pragmatic and effective system engineer-ing. Visitors often mention that all Space Departmentengineers seem to think like system engineers, whetheror not they have that title. Perhaps less well known isAPL’s record of innovative, yet practical, advancedtechnology developments. Many of the standard tech-niques used on today’s satellites were developed here.2

NS HOPKINS APL TECHNICAL DIGEST, VOLUME 20, NUMBER 4 (1999)

SYSTEM APPROACH TO SPACE MISSION DEVELOPMENT

A small but prolific advanced technology developmentprogram continues that tradition today.

This article provides a top-level view of APL’s mis-sion development process, from mission objective tolaunch. Postlaunch operations and certain other as-pects of mission development require the more detailedtreatment given by the subsequent articles in this sec-tion. A strength of the APL Space Department hasbeen our “end-to-end” approach to mission design andexecution (Fig. 1). The close working relationshipbetween space scientists and engineers fosters a symbi-osis that is the hallmark of APL missions. Such close-ness in a single organization is surprisingly unusual inthe space industry; the fact that these two groupsunderstand and empathize with each other—not justtolerate each other—is even more rare. The resultingability to provide “one-stop shopping” for governmentspace customers has contributed greatly to APL’s recordof success with better, faster, cheaper space missions.3

UNDERSTANDING THE PROBLEMThe article by Bostrom in this issue (“Defining the

Problem and Designing the Mission”) addressed theearly concept and mission formulation phase. Everysuccessful program must be able to state its objective,preferably in one concise sentence. (Possibly the bestexample of a concisely stated objective was PresidentKennedy’s 25 May 1961 statement to a joint session ofCongress: “I believe that this nation should commititself to achieving the goal, before this decade is out,of landing a man on the moon, and returning him safely

Figure 1. The APL Space Department provides complete end-to-end mission design andexecution capability, fostered by the symbiosis between our scientists and engineers. Abasic mission concept can be taken completely through development, launch, on-orbitoperations, and analysis of the scientific data within a single organization, at substantialbenefit to our government customers. At the same time, we are alert for opportunities tocross-fertilize technologies to other missions or transfer them to industry, and for educationand outreach opportunities.

Missionconcepts

Missionoperations

Hardwareimplementation

Launchoperations

Results andpublications

Dataacquisition

and processing

Fundamentalscience and

technology driversTechnology

synergy

Technology transfer

Educationand outreach

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 20, NUMBER 4 (1

to Earth.” It is important to remember that at the timeKennedy set out this bold objective, the United Stateshad not yet orbited a single astronaut—John Glenn’sfirst orbital flight was still 9 months away. Kennedy’ssingle sentence not only stated the objective of whatbecame the Apollo Program, it set forth the schedule aswell!)

The objective isolates and pinpoints what is trulyimportant; the value of a well-crafted objective cannotbe overstated. It establishes the criteria by which mis-sion success or failure will be judged, possibly manyyears down the road. It serves to periodically refocus theattentions of the team on the essential purpose of themission, which might otherwise be forgotten in theforest of design details that accrue as time passes andas staff and subcontractors join and leave the program.Most importantly, it helps guard against “requirementscreep,” that deadly malady that has threatened morethan one program.

The objective also isolates and emphasizes the essen-tial kernel of why the mission is being done. Where doesthe objective come from? It can arise from a committeesuch as a science working group, user working group,or study team. But some of the most impressive break-throughs have come from objectives set by a proverbial“wild-eyed sponsor,” one champion obsessed with solv-ing a particularly tough problem or performing a par-ticular mission.

Once the top-level objective is established, a con-cept for meeting the objective is synthesized. That greatsystem engineer Julius Ceasar provided the key to solv-ing the really difficult, large problems: divide and con-

quer. The problem is broken downinto smaller pieces, and subsidiaryfunctional requirements are estab-lished, a process known as “require-ments flowdown” (Fig. 2). Thisprocess of synthesis and analysisrepresents a very creative part ofthe mission design, with frequentiterations back and forth betweenalternative conceptual approaches,while keeping in mind the avail-able capabilities and the numerousconstraints (mass, schedule, cost,and a host of others). Deciding howto partition the system and whereto establish the interfaces is almostan art form. Interface decisionsmade at this time can haunt (orbless) a program for its duration.

“Brainstorming” is one of thetechniques used in this early stage ofsearching for conceptual solutions(see the section on The DesignProcess). Numerous books teach

999) 483


Missionobjective

Capabilities Functionalrequirements Constraints

Missiondesign

Missionanalysis

Launchvehicle

requirements

Missionoperations

requirements

Spacecraftrequirements

Block, power-flow,and signal-flow

diagrams

Specs, interface control documentsOrbital configuration (interior, exterior)Launch configuration (and vehicle adapter)

Figure 2. Starting with the all-important mission objective, topfunctional requirements are established, taking into considerationthe available capabilities and the imposed constraints. A solution—the mission design—is synthesized by an iterative process ofanalysis and design. Subordinate requirements on the launchvehicle, spacecraft, and its subsystems, along with mission opera-tions, are then “flowed down” from the top-level requirements.

brainstorming techniques and other useful conceptual-ization principles (see, for example, Refs. 4 and 5). Akey to successful program management is the systemstability that comes from an early freeze of the functionalrequirements. A worthy goal is to freeze them at thefirst system-level design review, typically the Concep-tual Design Review.

In the course of this conceptual design process, thesystem drivers will become apparent. System drivers aremajor requirements whose satisfaction will establishone or more key attributes of the design. A spacecraftwill often “look the way it looks” because of its systemdrivers. And system drivers are often highly leveraged:a small change in the requirement can lead to a bigchange in cost, schedule, or technical risk.

Once the top-level mission design concept has beensynthesized, analyzed, and validated, the next level offunctional requirements—for the launch vehicle, thespacecraft, the instruments, and mission operations—can be captured. Now, the familiar system engineeringtools come into play: block diagrams, power and signal

484 JOH

flow diagrams, specifications, interface control docu-ments, and test plans.

The Delta 180 mission provides a good example offocusing on the true objective and meeting it through“out-of-the-box thinking.” Soon after President Reaganchallenged the military to develop a missile defense, thenewly established Strategic Defense Initiative Organi-zation (SDIO) wanted a quick and convincing demon-stration of space intercept of a thrusting target. Variousaerospace organizations proposed mission concepts, butthey were all too long (3–5 years) and too expensive($300–500M). One reason for the high costs wasthat all of these concepts envisioned separate launchvehicles for the target and the interceptor. APL systemengineer Michael Griffin and program manager JohnDassoulas considered the essence of the problem andcame up with the novel idea of carrying both target andinterceptor on a single, low-cost Delta launch. Further-more, both spacecraft could be assembled from sub-systems scrounged from various existing missile andlauncher systems. SDIO accepted the concept, and theDelta 180 intercept was successfully carried out only 13months from funded start, at a total program cost of$150M. Delta 180 received a presidential citation, twoDoD distinguished public service medals, and awardsfrom the American Institute of Aeronautics and Astro-nautics (AIAA), the American Defense PreparednessAssociation, and Aviation Week & Space Technologymagazine. It was even popularized in Reader’s Digest.6

This demonstration of what could be done quickly,successfully, and at low cost for one government cus-tomer in 1985 started NASA thinking about its own“better, faster, cheaper” program.

ORGANIZING THE TEAMOne feature of APL’s development process is the or-

ganization of teams. Each team has clear lines of respon-sibility for the execution of the mission, but in additioneach team member has an understanding of other ele-ments of the system. This widespread “system engineerthinking” results in a more robust system design, withthe team retaining ownership of the entire process fromconcept to on-orbit operations. This culture—which isnot as widespread in the aerospace community as onewould expect—began with the Transit Program and canbe seen today in the teams that produced ACE andNEAR and are working on missions such as TIMED(Thermosphere-Ionosphere-Mesosphere Energetics andDynamics). This culture also reinforces the all-impor-tant ties between the scientists and engineers.

The article by Bostrom summarizes how the wholeidea of Transit evolved from the work of GeorgeWeiffenbach, William Guier, and Frank McClure.Richard B. Kershner led the development of Transit,and it was his leadership and his choice of staff that set



the tone for what followed. Kershner not only led, butactively participated in the development. He cajoled,challenged, and stimulated his colleagues as they tack-led the various problems associated with the creationof one of the first practical and useful space systems. Atthe outset of the program he established a workinggroup of the principal engineers and scientists, withhimself as the “chief system engineer.” In this role hesaw to it that each member of the program leadershipunderstood the problems in all of the constituent partsof the effort and created solutions in their area ofexpertise that took into account the effect on the sys-tem as a whole.

This divide-and-conquer process of parsing a systeminto component parts with well-defined interfaces andrequirements, while keeping the requirements of thetotal system always in mind, resulted from Kershner’swork in the early guided missile development activitiesat APL. Kershner was responsible for the developmentof the Navy’s Terrier guided missile in the 1950s. To getreliable missiles built by the prime contractor, a processof well-defined subsystem requirements was imple-mented, with documented interfaces and a test programthat ensured the integrity of each subsystem prior tointegration. This methodology has been central to theSpace Department’s success throughout its history.

Resolving Conflict Among Many RequirementsNASA asked APL to use its expertise in small sat-

ellites developed for Transit to create a low-cost space-craft bus capable of launch on the smallest operationallaunch vehicle, the Scout. By the time of the SmallAstronomy Satellite (SAS) Program, the system engi-neering culture and the practice of delegating sub-system leadership and responsibility to lead engineerswere firmly established. The development team used itssystem understanding to refine the mission require-ments proposed by outside scientific teams into con-cepts that met the small size and low cost requirements.Four satellites—SAS-A through -C and Magsat—werelaunched in this series. In many ways, APL’s work onthe SAS Program anticipated the “reinvention,” yearslater, of NASA’s lightsat concepts of small, capablesatellites and common, interchangeable buses.

Under the APL lead engineer concept, a single en-gineer has technical, cost, and schedule responsibility fora particular subsystem from concept to postlaunch. Thisincludes conceiving the design approach; preparing aproposal; performing detailed design; defending thedesign at peer reviews; seeing the design through layout,detailing, and fabrication; performing qualification test-ing; assisting with integration onto the spacecraft; andproviding postlaunch support. These tasks may transpireover a 2- to 3-year cycle and typically involve leadinga small team of support engineers, technicians, and

JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 20, NUMBER 4 (

designers. The whole experience proves exciting andbroadening to our engineers; it helps them see the bigpicture and start thinking like system engineers.

Forming the Engineering and SciencePartnership

The Active Magnetospheric Particle Tracer Explor-er (AMPTE, Fig. 3) exemplified the bridge between thescience and engineering sides of the Space Department.The requirement to understand the effect of the spaceenvironment led to the establishment of a group inter-ested in a large class of space physics problems. EarlyAPL satellites flew instruments to answer problemsdirectly related to Transit’s needs. The instrumentationexpertise developed in these investigations led to col-laboration between APL investigators and colleagues atNASA and throughout the world. The scientists whodeveloped the AMPTE mission concept were able to

Figure 3. The AMPTE mission integrated science and technicalteams in three countries to build the Charge Composition Explorer(APL), Ion Release Module (Max Planck Institute, Germany), andthe United Kingdom Subsatellite (Rutherford-Appleton Laborato-ries and Mullard Space Science Center). The active nature of thescience plan called for near–real-time measurement and control,and required the development of a real-time science data center.The interaction among the science team members, spacecraftdevelopers, and mission operators was facilitated by APL’s heritageof close cooperation between scientists and engineers.

1999) 485


draw upon the Department’s engineering skills to de-velop and execute the mission. The Transit culture ofusing small, integrated engineer/scientist teams to de-fine and lead the execution of a complex mission waseasily adapted to the execution of this complex sciencemission, which involved the launching of three space-craft at one time.

FABRICATION OF RELIABLEHARDWARE

The development of space systems requires thatunique, one-of-a-kind units be fabricated and assem-bled with the quality of the best production line oper-ations while retaining control of the cost. During theearly years of the space program at APL, the fabricationprocesses were closely associated with the teams per-forming the engineering. Many space reliability inves-tigations were conducted with the 5E series of space-craft. The 1962 Starfish nuclear blast gave furtherimpetus to understanding and defending against theradiation environment. To ensure that the systemsdeveloped by the Department were of the highestpossible reliability, the detailed design, fabrication, andquality assurance functions were refined and staff withunique skills were recruited. These people eventually
formed the core of today’s SpaceReliability and Quality AssuranceGroup as well as the Electronicsand Mechanical Design and Fabri-cation Groups in the TechnicalService Department. (These top-ics are treated more completely inRef. 7 and in the article by Ebertand Hoffman, this issue.)
INTEGRATING“INTEGRATION” WITHOPERATIONS

The evolving complexity ofspace missions has driven the as-sembly and testing of the flightcomponents and the developmentand testing of the operationalground segment into one activity.The primitive technologies andlimited reliability available duringthe early days forced us to keep asmuch of the control and complexityof the mission as possible on theground. We did in space only whathad to be done in space, and thenas simply as possible. A small num-ber of measurements sufficed to

486 JO

verify proper spacecraft operation, and the rudimentarysatellite designs had few operational states to test. Forsuch missions, space and ground segments could beverified independently; there was little need to bringthem together until shortly before launch.

Today’s more complex missions demand more com-plex spacecraft. To keep this increased complexity fromoverwhelming the development process, the Depart-ment merged its integration and operations activities.The use of simulators for both ground testing and com-mand upload verification (as on ACE, NEAR, MSX,and TIMED) is one positive outcome of the consoli-dation of these activities into a single functional group.

TIMED is taking integration one step further byproviding seamless, independent operation of four in-struments from four geographically separated organiza-tions.8 The development of this system entailed tworequirements: (1) each instrument team had to havecommon ground systems that simulated the spacecraftinterfaces, and (2) each team had to be able to interfacetheir instrument’s unique ground equipment to the sim-ulator and ultimately (via the Internet) to the satelliteoperation facility. The mission operations plan allowsthe principal investigators at each institution to bothsupport testing of their instrument and to operate itduring flight from their home institution (Fig. 4).

Figure 4. The TIMED operations concept relies on the ability of the spacecraft and itsinstruments to operate independently. Onboard status and data are downlinked to the APLSatellite Control Facility where instrument and spacecraft data are routed to the teamsresponsible for these different elements. Real-time or packetized data can be sent vialocal-area networks or the Internet. Each team will assess the data, plan future operations,and create appropriate commands at their home institutions. (C&DH = command and datahandling, MDC = Mission Data Center, MOC = Mission Operations Center, POC = PayloadOperations Center.)

Instrumentcommendexecution

Instrumentcommandpackets

Commandbits

C&DHcommandexecution

Instrumentcommandexecution

C&DHrouting service

Buscommandpackets

Commandbits

Instrument commandchannel

Bus commandchannel

Instrumentdata

collection

TIMED spacecraftbus data collection

Telemetrypackets

Telemetrypackets

C&DH combined

C&DHrecording

C&DHframe

packaging

Real-timepackets

Playbackpackets

MOCplanning

Spacecraftsubsystemcommandpackets

Results

MOCassessment

Spacecraftsubsystem

packets

Real-timechannel

Playbackchannel

MDCcleanand

merge

Instrumentpackets

POCplanning

Instrumentcommand

packets

Products

Playbackinstrument

packets

Groundsystem

telemetryrouting

Real-timepacketsintegrationandtest

MOCauthorizationand routing

POCprocessing

HNS HOPKINS APL TECHNICAL DIGEST, VOLUME 20, NUMBER 4 (1999)


THE DESIGN PROCESSNASA and Air Force studies have shown that the

single most important technical element of missionsuccess is design. In one NASA study of more than 300spacecraft and launch vehicle failures, design error wasidentified as the single biggest cause—the item simplywas not designed properly in the first place.9 The Lab-oratory had independently reached this same conclu-sion long before such studies were conducted and in-stituted a rigorous design integrity program thatincluded a thorough design review process. Many of thedetails of this design integrity program are treated in thearticle by Ebert and Hoffman, this issue, and will notbe repeated here. Suffice it to say that the list of con-siderations needed to achieve good design is a long one,and tight surveillance must be maintained on all ofthem in a balanced way.

The design process begins with a careful statementof the problem to be solved—the mission objectivedescribed earlier, or its subsystem equivalent. Focusingthen on the essence of the mission objective, innovativesolutions are often found by brainstorming, a specialtechnique in which designers within a group play offeach other’s thoughts to create the largest quantity ofpossible solutions to the problem. Critiquing is strictlyforbidden in a brainstorming session; the ideas will besorted through and examined later. Once the “baseline”solution is selected, the “wild and crazy” brainstormingmode must give way to an extremely conservative,worst-case mindset for actually implementing the de-sign. So between analyzing and synthesizing, brain-storming and critiquing, and worst-case designing,Space Department engineers are asked to operate overa wide dynamic range.

One of the most effective rules for achieving a re-liable design is to “Keep it simple!” For example, ahallmark of APL spacecraft designs is the effort madeto eliminate moving parts; thus NEAR differs fromprevious interplanetary spacecraft in that it uses a fixed(not gimballed) high-gain antenna, fixed (not rotat-able) solar arrays, and no instrument scan tables.

A thorough, rigorous design review process is a keypart of our design integrity program. The Department’sdesign review requirements are one of several guidelinesand standards set forth in the Space Department En-gineering Notebook, which is accessible to all staff.Space Department design review practices receive fa-vorable comments from outside organizations; in theultimate compliment, NASA Goddard Space FlightCenter (GSFC) adopted (with our permission) ourguideline as their own internal standard.

With the key functional requirements established atthe mission concept phase, the principal programdocuments cited earlier can be prepared. The SpaceDepartment approach uses the barest minimum of such


documentation, but committing things to paper (ormore likely today, its electronic equivalent) has twoimportant advantages: paper “remembers,” and the veryact of writing things down organizes the engineer’sthinking and exposes muddled logic. Often, especiallyin competed selections, a formal proposal will be re-quired that may stipulate an exposition of the designsimilar to a conceptual design review level of detail.Preparation of such a proposal is a miniprogram in itself.At this stage, the system engineer is earning his or herkeep by flowing down and apportioning requirementsto the subsystems in a balanced way, keeping the mis-sion objective foremost at all times. Of course, thisflowdown takes place amid constant consultation withthe subsystem lead engineers. Part of the system engi-neer’s job is to “spread the pain evenly” in apportioningthe requirements and resources; it’s often said that asystem engineer knows he has it right when all the restof the team members are equally angry with him.

As flowdown proceeds, it is important to distinguishbetween true requirements and “desirements” (whichare often best relegated to “goals”). For example, aclassic system engineering error is to set the require-ment to what someone said was “easy to achieve” ratherthan to the true minimal requirement as established byanalysis. When, months later, it turns out that “easy toachieve” has become painfully difficult, no one mayremember where the original requirement came from(the so-called “phantom requirement” problem). Sorequirements traceability, either kept in one’s head orpossibly managed by software, is an important part ofthe system engineer’s job.

Mission conceptual design occurs within numerousconstraints, one being the Space Department’s policyon margins. For example, a mission design is consideredviable only if it can show at least 20% margin on space-craft dry mass at the conceptual phase. Similar marginsapply to other important resources such as power, fuel,RF links, and processor memory and throughput. Someof these margin requirements taper down rationally asthe mission approaches launch (required mass margin,in fact, going to zero at launch). Both NASA and theAIAA have subsequently adopted and formalized thesetapered margin concepts.10

Good margin management is important not only toensure the credibility of proposed new concepts but alsoto ensure solid engineering once the program is underway. An example of how insufficient mass margin se-riously affected reliability is shown by APL’s worst-everin-orbit failure—the unsuccessful deployment of theTransit Improvement Program (TIP-2 and -3) solararrays. After a long investigation, the failure scenariowas determined to be as follows: the Scout launchvehicle heat shield was (intentionally) deployed at alower altitude than normal. That, coupled with an

999) 487


unusually shallow angle of attack, caused aerodynamicheating, which in turn caused the “carpenter rule”antennas to melt to their nylon guides, thereby pre-venting the release of the arrays. But why was the heatshield deployed early in the first place? It was to dealwith a lack of mass margin on the spacecraft!

An example with a better outcome shows how massmargin can rescue a mission. When NEAR’s mainengine burn aborted in December 1998 on entry to thetarget asteroid Eros, the recovery used much more fuelthan anticipated. However, NEAR carried ample delta(fuel) margin by design. In addition, NEAR at launchhad not zero mass margin but 6 kg. This extra massmargin allowed us to load extra fuel onto the spacecraft,and the extra fuel carried from this converted massmargin helped save the mission.

Eventually design must cease and fabrication (andcoding) begin. To ensure correct implementation of theapproved design, effective configuration managementis necessary. The Space Department uses the APL-standard configuration management system operatedby the Technical Services Department. This system iswell documented, and the staff in both departments arefamiliar with its requirements. Like other APL systems,it offers multiple levels of control, four in this case.Therefore, every element of every program need notoperate at the highest level of tightness of control fordocumentation and changes. The actual levels selecteddepend on the complexity and criticality of the pro-gram element. These levels are selected in advance anddocumented in the program’s Performance AssuranceImplementation Plan.

Understanding the EnvironmentMisunderstanding the environment is a favorite on

everyone’s list of why things fail in space. Much ofAPL’s early Transit work was, in fact, devoted to un-derstanding the space environment and its effects.Several of our early spacecraft were dedicated totally tomeasuring and understanding the space environmentand laid the foundation for the Department’s spacescience program.

Once past launch, the space environment can insome ways be more benign than many terrestrial envi-ronments (e.g., under the hood of a car). However,many subtleties and traps await the designer. Oneexample is “cold welding,” the phenomenon by whichtwo parts made from the same metal, in intimate con-tact in the hard vacuum of space and without theadsorbed layer of oxygen they would have on Earth,stick to each other as if welded. The existence of coldwelding is still controversial, but the APL-designed(RCA-manufactured) Nova-1 satellite (1985) seems tohave encountered it. Nova’s disturbance compensationsystem used a small cylindrical proof mass levitated

488 JOH

around a wire. This sensor controlled microthrusters tonull out drag and radiation pressure. After the systemhad been turned off for a month, the gold alloy proofmass appeared to have become “stuck” to the gold wire.It finally took a timed series of proof mass suspensioncurrent commands at the system’s mechanical resonantfrequency to break the cold weld loose.

The space radiation environment represents anotherunique challenge, affecting materials and, most espe-cially, electronics. Total dose and single event radiationeffects are the main reason why spaceborne processorslag typically 2 to 5 years behind their terrestrial coun-terparts. APL played a pioneering role in understandingthe space radiation environment and learning how todesign for it. The 1962 Starfish high-altitude nuclearblast demonstrated (unintentionally) how vulnerablesatellites could be, impacting our Transit 4B andTRAAC as well as many other non-APL satellites.With the critical Navy Transit System to protect, APLsoon became expert in designing not only for the nat-ural radiation environment, but for the nuclear weapon“enhanced” environment as well (see Ebert and Hoff-man, this issue, for a fuller discussion).

The Buy Versus Build DecisionOne important early decision for each element of the

spacecraft—even for the entire bus itself—is “buildversus buy.” By “build” we mean to produce within APLrather than purchase, and even this selection has twochoices: to design from scratch or to “build to print” aprior APL design. The question is really therefore “de-sign, rebuild, or buy?” A complex array of factors, bothtechnical and managerial, must be considered. Theseinclude the obvious ones like cost, schedule, and per-formance and also such “soft” issues as staffing availabil-ity and the workloads in the Space and TechnicalServices Departments.

Designing and building in-house provides the verybest control on quality and schedule. And—let’s behonest about this—it provides more fun for our engi-neers. But in today’s highly cost-constrained programs,we must make these decisions totally objectively. A“heritage” design (i.e., bringing over a design from aprior successful use on another program) can save timeand money, but has its own set of pitfalls. To begin with,is the prior design sufficiently well-documented for arebuild, and are parts still available? Second, what isdifferent in this application (performance? interfaces?environment? what?)? In the early days, having a com-patible structure for some new start-up was consideredexcellent heritage, as with the Geodetic Earth OrbitingSatellite (GEOS-A) to the DoD Gravity Experiment(DODGE). Today, it’s software! But the space businessis fraught with disastrous examples of misappliedheritage designs, the most expensive possibly being the



incorrect reuse of a guidance software module on Ari-ane V’s maiden flight—a $700M mistake!

Sometimes the sponsor will force the “design, re-build, buy” decision for us: APL wanted very much todesign and build the Magsat Attitude Transfer System,but NASA decreed that we subcontract it to industry.For GPSPAC, the first spaceborne GPS navigationsystem, APL wanted to design and build the GPS re-ceiver/processor itself, but the sponsor directed that wesubcontract it to industry.

The Laboratory also instituted a system to best use“heritage parts.” In addition to our system for buyingscarce flight parts on overhead and then selling themback at cost to programs (see Ebert and Hoffman, thisissue), we long ago instituted an efficient way to trans-fer parts between programs. The Delta 180 Program wasone of the first beneficiaries, buying many of its partsfrom AMPTE residuals. The reimbursement funds thusearned by AMPTE were then used to fund its ScienceData Center. NEAR benefited similarly from MSXresiduals, and the Jet Propulsion Laboratory used avariant of the system to sell Cassini residuals to Mars/Pathfinder. Despite providing a clear win–win situationfor both programs, both government sponsors, andAPL, this cost-reimbursement system is under constantscrutiny by auditors and is always in jeapordy.

Reliability Apportionment and RedundancyReliability apportionment and redundancy are key

decisions that must be made early in the design of anysystem or subsystem. Few programs can afford the oldmethod of simply specifying that “no single point fail-ure shall cause loss of the system.” Although easilystated, that requirement can be painfully difficult andexpensive to meet, and then to validate through anal-ysis, review, and test. In making redundancy trades, itis important to resist the temptation to simply addredundancy where it is easy or to make redundant thoseboxes that were made redundant on the last project.While hardly anyone today places much faith in theabsolute numerical predictions of MIL-217–type reli-ability analysis, analysis of this type is, in fact, usefulfor conducting sensitivity analyses to show where ad-ditional reliability is needed and for comparing twodifferent topologies, particularly redundant versus non-redundant.

Redundancy can involve more than simply addinga second box. Much of the effort in developing APL’sIntegrated Electronics Module (IEM), for example,went into ensuring failure-proof implementations ofthe signal backplane and power distribution to theindividual cards. These architectural sophisticationsgreatly increase the flightworthiness of the IEM andmake it much more than just “a bunch of cards in a cardcage.” Sometimes the reliability requirement can be


met by using functional redundancy instead of addinga duplicate box. For example, if a star camera shouldfail, its function might be accomplished, in a degradedway, by using a visible imager carried as part of thescience payload.

Risk Management“It’s incredible how much bizarre stuff on Triad

worked!” says John Dassoulas, Triad Program Manager.APL’s Triad was the first satellite to fly a pure gravita-tional orbit, free of the drag and solar pressure pertur-bations experienced by all other satellites. It did this byflying a spherical proof mass in a shell, shielded fromall nongravitational effects, and keeping the satellitecentered around the proof mass by firing microthrust-ers. Triad was built in three parts separated by boomsto control local gravitational attraction. And as if allthis wasn’t complicated enough, it was powered by aradioisotope thermal generator (RTG) power source.Yet, it worked perfectly. Likewise, the Delta 180 mis-sion, designed and executed in 13 months and involv-ing 2 space vehicles, 38 ground radars, 6 airborneobservation posts, and 31 satellite links, performed thefirst thrusting space intercept flawlessly. How are suchthings possible?

It’s been said that all of project management is riskmanagement. Risk is the probability of some programelement having an unfavorable result times the severityof the consequences (Fig. 5). A project can face tech-nical, cost, schedule, or political risk. Technical risk—the subject here—can be evaluated in design reviewsand in other formal, independent risk assessments.Probabilities are usually quantized to low, medium, and

0 1Probability of event occurring

Lowrisk

Mediumrisk

High risk

Adv

erse

con

sequ

ence

s of

eve

nt

Figure 5. Expected risk of a particular item is the product of theseverity of the consequences and the probability that it will occur.Once risk items are identified and rank-ordered, they can receiveadditional program surveillance or other risk mitigation actions.

999) 489


high, and “traffic light” charts (green, yellow, red) canprofile the risk areas on a complex program. High-riskareas, once identified, can be mitigated in a number ofways. Ideally, the risk area, or the design driver thatcreated it, can be designed out of the system. Failingthat, early risk reduction experiments, or building pro-totypes or engineering models, may provide an earlyassessment of the true risk. Extra margins can be carriedfor high-risk elements. Surveillance of the risk item willsurely be increased. Finally, no program today is with-out its “descope plan”—a predetermined, prioritized listof features, or even entire subsystems, that can be de-leted in a pinch. Descoping is obviously a last resort,but the later it is done the smaller the payoff. That iswhy early recognition of risks is so important.

Technical risk can result from reaching for unreal-istic performance, beyond the state of the practice. Itcan arise from system complexity and the sheer numberof interfaces. Changing requirements is a commonsource of risk, which is why an early requirements freezeis essential. Risk can arise at any stage where somethingcan go wrong that sets the effort back: part orders wrongor late, components destroyed during fabrication, sys-tems damaged in test, mission operations errors—thelist is long. There is risk in the launch itself (about 3%of launches end in failure; in the early days it was 30%),and finally from lifetime and aging issues once in orbit.Modern risk management11 attempts to organize andanalyze semiquantitatively all ofthese risks and to mitigate themwhere economically feasible. Inthis way, risk management merelyformalizes what successful programmanagers have been doing “in theirhead” for years. PERT (ProgramEvaluation and Review Technique)charts and critical path analysis areexamples of risk management toolsapplied to scheduling.

In today’s programs, softwaredevelopment is invariably on therisk list. (The standard rule, for in-stance, is that software is always90% complete.) The ability to re-load software to modern spacecrafthas, if anything, not helped becauseit now presents the irresistibletemptation to deliver at least someof the software after launch. Sevenyears ago, the Space Departmentissued its Software Quality Assur-ance Guidelines12 to bring uniformstandards and discipline to softwaredevelopment, with different de-grees of tightness of control de-

Figure 6. An elememissions is the abilitprograms and for a vAGRE = Active GeoATD = Advanced Tetion, DNA = DefensUltraviolet TelescopNational Polar OrbitAtmospheric AdminiOperational Environ

DoD(partners since

APL missionFAC

APEXAGREMSX

DMSPMMIC-based raDelta 180, 181,

GeosatPolar BEAR

HILATTriad

DODGE

DoD techno• BMDO (phenome• Air Force sensor d• Navy altimetry, na• DNA/ionosphere

490 JO

pending on the risk. The success of

this approach has been proven on such programs asMSX, whose 54 onboard microprocessors required thesuccessful development of 280,000 lines of flight code.

EVOLUTION OF THE TECHNOLOGYBASE

The space program evolved a significant technologybase to meet its own needs and produced countlesstechnology spin-offs that benefit other sectors of theeconomy. The Space Department has made importantcontributions in this area, capitalizing on its traditionof identifying needs in new areas, or for different spon-sors, that can benefit from solutions developed to solvepast problems (Fig. 6). Working at the boundariesbetween differing problem sets promotes viewingnew problems in different ways and is a proven ap-proach to creativity.5 APL’s history of transferring tech-nology between DoD- and NASA-sponsored programsprovides many examples (magnetic attitude control,heat pipe thermal control, autonomous onboard nav-igation, delayed commanding, etc.). There are, in ad-dition, numerous examples of transferring these tech-nologies into apparently unrelated areas, such asbiomedicine and environmental assessment. This heri-tage of cross-fertilization and technology transferprovides an important element in the Department’ssupport of our customers.

nt in the Space Department’s success across a broad range ofy to leverage and cross-fertilize technologies developed on differentariety of sponsors. (Acronyms not defined in the text are as follows:physical Rocket Experiment, APEX = Active Plasma Experiment,chnology Development, BMDO = Ballistic Missile Defense Organiza-e Nuclear Agency, FAC = First Alert and Cueing, HUT = Hopkinse, MMIC = Monolithic Microwave Integrated Circuit, NPOESS =ing Environmental Satellite System, NOAA = National Oceanic andstration, NSF = National Science Foundation, POES = Polar-orbitingment Satellite, SIR = Shuttle Imaging Radar, STEREO = Solar Ter-

restrial Relations Observatory, UARS = Upper Atmospheric Research Satellite.)

1959)

s

dar 183

NASA(partners since 1961)

APL missionsSTEREO

CONTOURTIMEDFUSEACE

NEARSounding rocketsCassiniSIR-CTopex

UlyssesGalileoVoyager

HUTGeotailUARS

AMPTEMagsatGEOS

NOAA, NSF, other(partners since 1965)

APL initiatives/missions

POES, NPOESSSmall Satellite Study

Flare GenesisSolar Telescope

SuperDARNFreja (Sweden)Project MagnetAircraft/ozone

Army–Navy–NASA–Air Forcelogynology)evelopmentvigation

NASA technology• APL IR&D• USAF sensor development• Program/project funds• ATD funds, 1999

U.S. new technology pipeline

Basic research• Concept definition• Balloon programs• Surveys• Radars• Sounding rockets



The development of ultra-stable oscillators (USOs)exemplifies the synergism across multiple sponsors of acritical technology and its value to the community.APL’s USO development began with the need for astable frequency source for the Transit Doppler naviga-tion satellites and the realization that such a sourcecould not be procured. A small team perfected thedesign, systematically balancing the circuit parameters,mechanical and thermal design, and the manufacturingprocesses.

Over the years the team improved the state of theart to meet ever-increasing performance demands fromthe technical community (Fig. 7). More than 400 APLflight oscillators have provided precise timing for nav-igation requirements and for probing the atmospheresof planets and their moons. The Laboratory is recog-nized as “the only credible source for [ultra-stable os-cillators] when cutting-edge performance is needed”(personal communication, A. J. Kliore, Cassini RadioScience Team Leader, and C. L. Hamilton, CassiniRadio Science Instrument Manager, 23 Oct 1998).Until recently, the number of USOs required annuallyhas been too small to make it a profitable commodityfor industry. But the coming of constellations of satel-lites such as Iridium and Teledesic, with their need forprecise timing, could soon change that.

Another area in which the Department has workedacross sponsor boundaries to cross-fertilize the technol-ogy base is radar altimetry. Early work in this field wasperformed for NASA. But the early demise of NASA’sSeasat left the Navy with a critical, unmet needin developing an improved gravity field model. The

Figure 7. The stability of spaceborne quartz crystal oscillators hasbeen steadily improved by the Department’s technical staff inresponse to requirements for ever-increasing performance from avariety of customers. APL has delivered more than 400 flightoscillators for navigation, tracking, and radiometric science.(Red = aging rate, green = 1-s Allan variance, blue = 100-s Allanvariance.)

10–14

10–13

10–12

10–11

10–10

10–9

10–8

1960 1965 1970 1975 1980 1985 1990 1995 2000

Year

Freq

uenc

y st

abili

ty, ∆

f/f

Cassini


Department quickly responded to this need by devel-oping the Geosat mission; the satellite performed flaw-lessly for 5 years. The latest in this series is APL’saltimeter on the Topex satellite, which is currentlyproviding data to study the El Niño/La Niña cycles inthe Pacific Ocean. New requirements for altimetricmeasurements over global ice fields have led the De-partment staff to develop an entirely new class of in-strument—the Delay Doppler Altimeter13—that com-bines two areas of radar science: classical altimetry andsynthetic aperture radar (SAR). The instruments re-sulting from “working across the boundaries” have 10times better along-track resolution and radiated powerefficiency. The Delay Doppler Altimeter may enablemissions as varied as ice measurements on Earth and onJupiter’s moon Europa and the future oceanographicneeds of the Navy.

INTEGRATION, TEST, AND LAUNCHOPERATIONS

Integration, test, and launch operations are the mostexciting parts of any satellite program. At integration,the months of planning, design, fabrication, and sub-system qualification finally result in something thatlooks like a spacecraft. Testing is always interesting,often exciting (but it shouldn’t be too exciting), andspiced with the occasional intellectual challenge oftroubleshooting anomalies. And what can be moreexciting than the final, fiery launch of your spacecraftinto orbit?

Delivering a quality spacecraft requires careful andconservative design, rigorous independent review,meticulous assembly, and thorough testing. Each linkin this chain must be strong. Protecting test time isalways a challenge, especially as schedules get squeezedfor “better, faster, cheaper” programs. But test we must,and it is a wise program manager who “fences off” andprotects a substantial block of test time at the end ofthe program. As Orlando Figueroa, then ExplorersProject Manager at NASA/GSFC, put it, “Test, test,and then test some more. Do it early.”

One way to preserve schedule time for a thoroughtest program is to speed up the integration phase itself.APL’s IEM, which carries nearly all the spacecraft buselectronics in a single card cage, and the R/IO (remoteinput–output) chip, provide examples of how this canbe done. Besides eliminating a significant amountof time-consuming (and heavy) harnessing, when aflight-qualified IEM is delivered to the spacecraft, asubstantial amount of integration and qualification hasalready taken place. Even spacecraft from our pre-IEMgeneration can make system decisions that speed upintegration. With NEAR, for example, the entire pro-pulsion system was purchased with its own substructurein order to save valuable integration time. The resulting

99) 491


mass penalty was less important than the schedule timesaved.

How best to spend that test time is a subject ofcontinual debate in the space community. Records oftest failures, which are very difficult to obtain fromother organizations, are constantly scrutinized to seewhich tests have the most payoff (Fig. 8). Testing hasbecome even more complicated as we enter the era oflarge constellations of identical satellites like Iridium.Even smaller constellations (e.g., Transit), and now ourfour-spacecraft Auroral Multiscale Mission, have toaddress exactly what testing makes sense, especially forthe 2nd through nth satellites.

The Space Department’s test standards were firstcodified in the Integrated Test Plan for Space PayloadEquipment,14 a 1968 document that predates even thevenerable MIL-STD-1540 Air Force test specification15

(the current version is Ref. 16). A revised version of Ref.14 (Ref. 17) is still the current test standard for ourflight hardware and systems. This document establishes

Figure 8. Testing time is precious, so it is important to know which tests have the highestpayoff. The Space Department constantly monitors its own and external test data to seewhich tests provide the most benefit and determine the best order in which to conductthem. Space Department test standards are codified in Ref. 17.

Tem

pera

ture

cyc

ling

Ran

dom

vib

ratio

n

Hig

h-te

mpe

ratu

re s

oak

Ele

ctric

al s

tres

s

The

rmal

sho

ck

Sin

e vi

brat

ion,

fixe

d fr

eque

ncy

Low

-tem

pera

ture

soa

k

Sin

e vi

brat

ion,

sw

ept f

requ

ency

Com

bine

d en

viro

nmen

t

Mec

hani

cal s

hock

Hum

idity

Acc

eler

atio

n

Alti

tude

360

330

300

270

240

210

180

150

120

90

60

30

Wei

ghte

d ef

fect

iven

ess

of e

nviro

nmen

tal s

cree

ns

492 JOH

minimum mandatory tests that all Space Departmentflight hardware must meet, as well as a menu of recom-mended optional tests.

Particular attention is given to “protoflight” testing,recognizing that hardly any program today can affordthe luxury of a full qualification model that does notfly. Under protoflight rules, the first unit built is the onethat flies. Therefore, careful compromises in such fac-tors as test levels and durations must be worked out toreplace the previous qualification and flight tests.

The order of tests is important as well. For example,experience has shown that it always pays to perform thethermal testing after the vibration testing (which is alsothe order in which these environments are experiencedduring launch). A Space Department rule is “test whatyou fly, and fly what you test,” i.e., the test article mustbe in flight configuration, or as close as possible, andother items cannot be added post-test (Fig. 9). Forexample, the last-minute NEAR fuel tank top-off citedearlier was made possible because NEAR had previously

NS HOPKINS APL TECHN

been vibration tested with 23 kg ofextra mass in the fuel tanks. Ournuclear-powered Triad spacecrafthad the first separable RTG heatsource, a big safety innovation. Butit meant that we couldn’t strictlyfollow our policy to test what we fly(instead we used electric heaters tosimulate the radioactive core).

Testing at the system level ispreceded by a hierarchy of lower-level subsystem and instrumentqualification tests, which help en-sure that system-level tests are rel-atively trouble-free. We believethat this admittedly conservativeapproach lowers overall cost andschedule risk and contributes toAPL’s record of reliability in space.

LESSONS LEARNEDIn any endeavor, but especially

in space, it is important to learnfrom one’s mistakes. Even better, ofcourse, is to learn from others’ mis-takes! As Barry LePatner, attorneyand witness before the House Sub-committee on Investigations andOversight, put it in 1982, “Goodjudgment is usually the result ofexperience. And experience is fre-quently the result of bad judgment.But to learn from the experience ofothers requires those who have theexperience to share the knowledge

ICAL DIGEST, VOLUME 20, NUMBER 4 (1999)

Figure 9. The yo-yo despin mechanism being tested on APL’sfirst satellite in 1959, under our philosophy of “test what you fly,fly what you test.” James Smola (extreme right, now retired) isconducting the test.

with those who follow.” Thus we have a tradition offiguring out and documenting “lessons learned” at theend of any major program or following any significantanomaly. The wise engineer and program manager willstudy these past lessons to prevent the ignominy ofhaving to repeat them.

To some extent, the “better, faster, cheaper” era ofstarvation budgets and iron-fisted management hasmeant that we must absolutely get it right the first time.There is no room at all for cut-and-try. In a way, thisrobs engineers of the opportunity to stretch out, to takerisks, and even, occasionally, to learn from failure. AsSpace Department founder Dr. Kershner is reputed tohave said, “We haven’t had a failure lately, so we’re notlearning anything.” Balancing risky progress againststagnant perfection is a dilemma we all face every dayin the space business.

BETTER, FASTER, CHEAPERDuring the early years, back-up satellites were rou-

tinely developed as part of most space programs.NASA, in fact, sent all of its planetary spacecraft outin pairs until 1989. The level of risk in those days



demanded that approach, and the budgets could sup-port it. APL’s first satellite, Transit-1A, was launchedin the fall of 1959 but failed to reach orbit. The back-up Transit-1B was successfully launched in early 1960and demonstrated the basic navigation concept. TheArmy-Navy-NASA-Air Force Program also built aprime and back-up satellite. Both were taken to CapeCanaveral for launch. During final checkout of theprime satellite, a fluctuation in the output power of atransmitter was observed. The back-up spacecraft wassubstituted during the flight countdown on T – 0 day;unfortunately, this launcher also failed to reach orbit.The original satellite was repaired and, when a secondlaunch vehicle became available, was successfully putinto orbit and operated for over 4 years.

Leftover subsystems or design elements were alsoregularly used in new ways to demonstrate new con-cepts. The TRAAC satellite was developed in only 75days—possibly a record—using elements from the earlyTransits plus a few new elements like the first gravity-gradient extendible boom.

The close-knit teams at APL continue to transformbasic designs into significantly different missions. TheMSX spacecraft used a wide array of processors, sophis-ticated attitude techniques that enable rapid slewingand precise pointing and tracking, and many otherimportant advances in instrumentation and communi-cation. Many of the MSX design concepts and a fewof the actual designs were transformed to form the coreof the NEAR spacecraft. For instance, the MSX visiblecamera designs evolved into the NEAR MultispectralImager. The X-band transmitter design was transformedinto NEAR’s X-band power amplifier. The controlsoftware for the NEAR Star Tracker was derived fromthe MSX tracker. NEAR also transformed APL’s ultra-violet spectrographic imager design developed for De-fense Meteorological Satellite Program (DMSP) satel-lites into an infrared spectrographic imager, savingprecious time and money.

Being alert to the potential for transforming systemelements from one program into the raw material fornew, very different missions is a feature of the innova-tion process and a key “better, faster, cheaper” concept.The emerging space business environment is providingan even wider set of raw material to complement theDepartment’s new concepts and internally generatedtechnology. This view is formalized in the Department’soverarching advanced technology goals, which includethe concept of system scalability and the use and trans-formation of commercial off-the-shelf products.

LOOKING TO THE FUTURESpace missions in the coming decades will require

a different mix of skills and partnerships from those ofthe past 40 years. But the complexity of these new

99) 493


missions will still require the kind of system engineeringviewpoint that has been at the heart of the APL cul-ture. These challenging new missions will also continueto need mission-enabling new technologies.

The maturity of the space industry has resulted in asignificant number of organizations that can providesystems and subsystems for many missions at lower costthan before. Reduced government space budgets areoffset by this commercial activity, which is also providingnew sources of technology investment. Both commercialand government programs contemplate many projectsthat require constellations of spacecraft where produc-tion line techniques are essential. Yet there remain asignificant number of unique, one-of-a-kind, cutting-edge missions. Although their mission focuses differ, bothgovernment and industry will need new technology andelegant system solutions to meet their goals.

Two important shifts by the Department respond tothis change in the space business environment and willsignificantly influence our mission development capa-bility. These are an increased emphasis on advancedtechnology and the recent decision to perform researchand development work for the commercial space indus-try. The type of cutting-edge science missions envi-sioned by Department scientists and their colleaguesaround the world as well as space-based solutions tonational security needs will require new technologies.Cost constraints on all of these potential programs willalso require elegant system solutions and the use of asmuch existing hardware and software as feasible. Therise of the commercial space industry provides oppor-tunities to use a wider range of system elements, includ-ing commercially procured satellite buses, to enablethese missions. Meanwhile, the opportunity to performresearch and development for the commercial spaceindustry may allow the Department to influence thetypes of system elements available for cost-constrainedmissions.

All of these scenarios will require the core compe-tencies of the Department: the ability to take a systemview of the mission, the science/engineering partner-ship, the ability to develop and exploit new and emerg-ing technologies, and the hardheaded practical expe-rience of the Department staff.

494 JO

New tools are emerging that will help us developthese new missions. These tools include modeling andsimulation advances as well as computer-aided designtools. Communications technologies allow the trans-mission of data sets to colleagues across the country sothat engineers can merge design elements throughoutthe industry. These new ways of developing spacemissions have a wider reach and allow the deeperunderstanding necessary to execute the most complexmissions, but at its heart it remains Dick Kershner’steam of experts sitting around a table.

REFERENCES1Artificial Earth Satellites Designed and Fabricated by The Johns Hopkins UniversityApplied Physics Laboratory, S. J. DeAmicis (ed.), SDO-1600 (Revised), JHU/APL, Laurel, MD (May 1987).

2Hoffman, E. J., “Spacecraft Design Innovations in the APL Space Depart-ment,” Johns Hopkins APL Tech. Dig. 13(1), 167–181 (1992).

3Krimigis, S. M., Coughlin, T. B., and Cameron, G. E., “Johns Hopkins APLParadigm in Smallsat Management,” IAA-B2-0601, in 2nd IAA Symp. onSmall Satellites for Earth Observation, Berlin (12-15 Apr 1999).

4Logsdon, T., Breaking Through: Creative Problem Solving Using Six SuccessfulStrategies, Addison-Wesley, New York (1993).

5Koestler, A., The Act of Creation, Hutchinson, London (1964).6Bennett, R. K., “Triumph at Pad 17,” Reader’s Digest (Jul 1987).7Wagner, G. D., “History of Electronic Packaging at APL: From the VT Fuzeto the NEAR Spacecraft,” Johns Hopkins APL Tech. Dig. 20(1), 7–21 (1999).

8Cameron, G. E., and Grunberger, P. J., “System Engineering of Cost EfficientOperations,” in Proc. Fourth Int. Sym. on Space Mission Operations and GroundData Systems (SpaceOps 96), SO96.8.003 (Sep 1996).

9Williams, W. C., “Lessons from NASA,” IEEE Spectrum, 79–84 (Oct 1981).10AIAA Guide for Estimating and Budgeting Weight and Power Contingencies for

Spacecraft Systems, ANSI-approved AIAA Standard, ISBN 0-930403-86-X(1992).

11Brown, I., Longanecker, G. W., and Madden, J. J., Risk Assessment for SpaceFlight, Applied Technology Institute, Clarksville, MD (Jan 1998).

12Lee, S. C., Hoffman, E. J., and Utterback, H., Space Department SoftwareQuality Assurance Guidelines, SDO-9989, JHU/APL, Laurel, MD (22 Oct1992).

13Raney, R. K., “A Down-Looking Satellite SAR with On-Board Real-RateProcessing: The Delay/Doppler Radar Altimeter,” in Proc. EUSAR ’96,pp. 189–192 (1996).

14Eckard, L. D., Jr., Wingate, C. A., and Frain, W. E., Integrated Test Plan forSpace Payload Equipment, SDO-2387, JHU/APL, Laurel, MD (1 May 1968).

15Test Requirements for Launch, Upper-Stage, and Space Vehicles, MIL-STD-1540(15 Apr 1974).

16Product Verification Requirements for Launch, Upper Stage, and Space Vehicles,MIL-STD-1540D (15 Jan 1999).

17Nagrant, J., Integrated Test Specification for Space Payload Equipment, SDO-2387-1, JHU/APL, Laurel, MD (Feb 1982).

ACKNOWLEDGMENTS: The authors are grateful for the information and “warstories” provided by members of the Space Department staff. We are especiallyindebted to John Dassoulas for his amazingly nonvolatile memory and willingnessto share his recollections.



THE AUTHORS

ERIC J. HOFFMAN received degrees in electrical engineering from M.I.T. andfrom Rice University, and joined APL in 1964. He has performed systemengineering for many of APL’s space communication and navigation systems, aswell as for entire spacecraft. He has supervised communications and navigationdesign activities and led satellite conceptual designs. As Space Department ChiefEngineer, he provides technical guidance for Department programs, promotessystem engineering, and sets standards for design integrity, design review,configuration management, and test. Mr. Hoffman has taught space systemsdesign courses at the Naval Academy, The Johns Hopkins University, NationalTaiwan University, NASA, and NSA. He has authored 60 papers on these topicsand is a co-author of Fundamentals of Space Systems. Mr. Hoffman is a Fellow ofthe British Interplanetary Society and an Associate Fellow of the AIAA. His e-mail address is [email protected].

J

GLEN H. FOUNTAIN received his B.S. and M.S. degrees in electricalengineering from Kansas State University in 1965 and 1966, respectively, andjoined APL’s Attitude Control Group in 1966. During his career at APL he hasheld a number of appointments and supported a range of programs includingthe Small Astronomy Satellite Program, the Transit Improvement Program,and Magsat. As Supervisor of the Space Science Instrument Group he ledthe ultraviolet and visible instrument developments for the Delta series ofmissions. Mr. Fountain was the Program Manager for the Hopkins UltravioletTelescope in the 1980s and the Special Sensor Ultraviolet SpectrographicImager in the early 1990s. He is currently the Supervisor of the SpaceDepartment’s Engineering and Technology Branch. His e-mail address [email protected].

OHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 20, NUMBER 4 (1999) 495

mailto:[email protected]

mailto:[email protected]

Documents

The System Approach to Successful Space Mission Development€¦ · The System Approach to Successful Space Mission Development Eric J. Hoffman and Glen H. Fountain onceptualizing