Lessons Learned from a Rapid Response Payload Development G. Murphy, T. Adams, K. Stewart Design_Net Engineering 303-462-0096 [email protected]

Lessons Learned from a Rapid Response Payload Development

G. Murphy, T. Adams, K. Stewart

Design_Net Engineering

303-462-0096 [email protected]

>>Responsive space means responsive payloads! <<

Responsive Space 2004 April 2004

Outline

• The Story and origin of the Floating Potential Probe

• Overview of Lessons Learned—the FPP Secret!

• Some example lessons:– Program Structure– Systems Engineering– Project Management– Responsive Software– Application of process—examples

• Summary


The Origin of FPP

• ISS solar arrays can pull the vehicle potential considerably negative because of current collection from the plasma– Too negative and arcs result– Need two-fault tolerant system to assure that crew does

not meet with disaster during EVA

• Plasma Contactor was designed to neutralize or “ground” the vehicle– No way to monitor whether it worked

• It was June of ’00, NASA was to fly the new arrays in November and there was no solution at hand


Origin (cont)

• Design_Net submitted a white paper to GRC/JSC with a crazy idea…– Refurbish a couple of old science sensors that had flown on a

previous shuttle mission which could be made to make this measurement

– House them in a small satellite that is attached to ISS by standard EVA hardware

– Carry the satellite up in the shuttle locker, assemble and deploy by EVA

• Nobody had any better ideas so…• FPP was born is late July of 2000• It was delivered for I&T at GRC on Election Day of 2000

– Less than 4 months after design began• This is the record of any delivered hardware for the ISS program—

they thought it had a 1 to 5% chance of success. How was this possible on a MANNED program???


FPP at KSC Awaiting Launch (Nov. ‘00)

The FPP (shown with thermal blankets, Probes, and Solar Arrays) is a Small Satellite w.o. an Attitude Control System


FPP Packaging for Launch and Interior Layout


FPP Mounting Configuration on ISS

StanchionAssembly


Lessons

• FPP was not a free-flyer BUT it had all the other subsystems of a normal satellite, it had a customer who was in a hurry, it had a payload, it had to find a way to “get to space” (by the way, it worked as designed)

• What did we learn from such a fast and “crazy” program???

• A LOT—a lot about what matters and what doesn’t matter for responsive space…lessons that should matter to leaders who attend this forum

• Are you ready for the secret???


The secret

• Its not about technology…Its about Process, People, Communication, Experience, Leadership, and Focus.

• Are you surprised? You shouldn’t be.

• Why didn’t I say hard work?? Of course its about hard work…We’ve all worked hard on lots of projects that were unsuccessful. Hard work is a necessary but not sufficient condition!!

• In the next series of slides we examine the program as an example and derive some concrete lessons that need to used for responsive payloads.


Program Structure

• Rapid Response means breaking the mold of the way we normally do business in aerospace– To do that you have to know the precise value of all that you do—

what can you change that affects schedule but doesn’t throw the baby out with the bathwater?

– Accept risk but manage it with people who understand where the real risk is, not the perceived risk.

• Partner with the customer and subs– You are in this together—play to each other’s strengths– Well defined roles and responsibilities– Frequent communication and face to face– Understand the customer requirements but keep them simple


Personnel

• Next to a good relationship with your customer and partners the most important thing is people—choosing your team– Find a combination of experience and the enthusiasm

of youth and let it work its magic– Make sure people are team players and good

communicators. No pet ideas allowed– If your team has never worked together before and

know each others strengths and weaknesses, this is going to be hard

• Minimize “trade studies” -- tap into the power of experience to choose the path of least resistance and “good enough” engineering


Interfaces

• No surprise here—keep interfaces simple– Strive for elegance in simplicity– Beat back bells and whistles with a vengence

• Make absolutely testable designs that are modular– Test at every stage, don’t wait until the end—if you think you

have to sacrifice testing and take risk to get it done fast you need to rethink how you do design and development

• Keep components as independent as possible from each other– This enables testing and rapid parallel development BUT

• This requires strong systems engineering


Systems Engineering

• Strong, experienced systems engineering is the single most important aspect of design– Assures reasonable partition of risk– Allows well-defined and testable interfaces– Promotes individual design efforts that complement

each other– Must be the “dictator” on technical disputes– Must be a very good communicator– Must work very closely with the PM– Works the customer technical interface– Must know the team


Project management

• Project Management of a fast track program also requires unique personal skills– Can’t be “managing” – must be leading, keep the focus– Must be willing to DO work not just supervise it– Don’t sit at your desk playing with ‘project’– Restructure schedule to manage risk on a daily basis– Must delegate responsibility to key subsystem

engineers– Communicate constantly– Hire an expeditor—engineers shouldn’t spend time

looking for things


Software

• The software design cycle must be extremely disciplined– Take the time to define the requirements—don’t just

start writing code– Keep architecture simple and modular– Testable, testable, testable—with hardware!– Minimize what the software has to do– Extensive peer review– Avoid S/W engineers with commercial and IT

backgrounds (sorry guys)—look for embedded experience, creativity, discipline and understanding of hardware


Examples

• Applying some of the engineering and teaming principles to FPP, we illustrate on the next two slides two specific subsystem components and processes where teamwork, creativity, systems design, communication, and simplicity of interfaces played key roles


Design Example:FPP Structural Design

• Allows external booms, sensors, antenna, or Solar Arrays to be mounted in a variety of configurations– 8 surfaces (six sides and 2 faces)– several locations on each surface– 8 clock angles per location

• Made of only 3 distinct mechanical parts

• Mechanisms that mate to the structure are standardized and have been flight proven (EVA assembly took about half the time expected)

• Design easily modified to allow “stacking” of units

• Fits in SS locker, dual height locker or in soft stowage


Programmatic Example:Safety

• “FPP” was a pathfinder for solving a number of issues associated with EVA deployment, Flight safety, launch manifesting, and transport of Small Satellite to ISS– battery approved by safety committee along with charging

algorithm– mounting locations and methods on ISS and worked out and

proven before flt– EVA mechanisms, design criteria, transport and assembly

procedures completed with 4 design cycles – training unit prepared for NBF in JSC– Locker and soft-storage packaging approved for flight– “pizza box” container solved glass safety issue

• Held a single safety review with key players gathered around the table


Satellite Deployment

The Tree was added to the solar array stowage bag because FPP “topped off”ISS with completion of the P6 Truss assembly


Summary

• Well defined responsibilities and teaming relationships which play to strengths

• Selection of team members experienced in their fields and with each other

• Experienced, creative, and measured system design that enables simplicity of interfaces and execution

• Design discipline that assures simple and testable software

• Involvement and communication with customer—think about testing, integration, and operations from the start

Documents

Lessons Learned from a Rapid Response Payload Development G. Murphy, T. Adams, K. Stewart Design_Net Engineering 303-462-0096 [email protected]