Personal Introduction

1
Personal Introduction
Brian Engberg
While a graduate student at Stanford University,
I was heavily involved with the Space Systems
Development Laboratory, under the direction of
Prof. Bob Twiggs

• Satellites and related projects that I worked on
• SAPPHIRE (Launched Sept 2001) CPU development
  team 1995-96
• OPAL (Launched Jan 2000) Project manager, lead
  systems engineer 1995-97 special advisor
  1997-2000
• SSDL ground station manager 1998-2000
• Orion (UNP Nanosat 1) Project manager, student
  PI, lead systems engineer, power system lead,
  Shuttle safety lead 1999-2001

I was hired by AFRL/VSSV in Oct 2001, and
currently work on a flight experiment program
called PowerSail I also provide peripheral
support to the University Nanosat Program
2
University Satellite Programs
So you want to build a satellite? Theres more
involved than equations and engineering
managing technical aspects are only a small part
of the effort A great deal of the educational
value lies in learning the subtleties of the
mission life-cycle process
What follows? lessons learned and
experience-based advice
Solve problems before they evolve A gram of
forethought is worth a metric ton of engineering

• Caveats on advice herein
• Different administrative constraints from
  institution to institution
• Experiences will be based on available talent
  pool and student interests
• Find and define methods that work for your
  particular program

3
Keys to Success

• Administrative and student leadership
• Roles and communication
• Organized mission and requirements approach
• Thought processes, logical planning, and team
  buy-in
• Good systems engineering practices
• Set up a good foundation early
• Personnel management
• Know your strengths and weaknesses

Technical challenges can be time-consuming but
poor project management can absolutely devastate
your schedule! It is far more likely that your
program will fail due to management problems than
due to a technical/engineering roadblocks!
4
Leadership Roles
Good communication paths are critical!
Professor
Students/Student PI

• Head of State
• Technical mentorship
• Executes expenditures
• Administrative support
• MUST empower students to
• complete tasks
• make design decisions
• productivity self-policing

• Head of Government
• Technical execution
• Financial decisions
• Administrative awareness
• MUST advise professor
• technical progress
• group morale
• facility needs

Prevent the need for the professor to step in
Step in only when necessary
Of course, if a professor wants to get their
hands dirty, that can be beneficial
too However, education should be student focused
5
Organized Requirements
Why is access to space required?
Mission objectives
Science goals
Mission Statement

• Clear, specific statement describing goals
  objectives
• Does NOT necessarily require justification
• Should not, in general, specify requirements

Why?
Mission Goals Requirements

• Clear, specific statements describing mission
  products methods
• Define minimum success and preferred goals
• In general, should drive (but not specify) system
  requirements

How?
System Requirements / Operations Plan
Operational Requirements
Subsystem Requirements
6
Mission Statements
Crappy MS (too general) The purpose of Program X
is to learn about magnetic-molecular chemistry
effects in the upper atmosphere by using
microsatellites
Good MS The purpose of Program X is to
investigate the effect of Earths magnetic field
on molecular chemical reactions in the upper
ionosphere this will be achieved by taking data
on orbit with a novel dual-band antenna sensing
device, after which the data will be returned to
the ground for processing.
Crappy MS (too specific) Chemical reactions
between oxygenated molecules in the upper
atmosphere are theorized to have a strong effect
on weather patterns over large bodies of water
such as the oceans. As such, the purpose of
Program X is to investigate the effect of Earths
magnetic field on atomic oxygen and ozone
reactions in the F1 and F2 layers of the
ionosphere this will be achieved by taking data
with a novel dual-band antenna sensing device
attached to a microsatellite not to exceed 50 cm
cubed in size and 50 kg in mass. The data must
be returned to the ground within 12 hours of
capture so that it can be processed using the
revolutionary Technique B.
The worst MS is not to have one at all!!!!
7
Mission Goals and Requirements

• Good Examples
• At least one complete continuous orbit of payload
  data, taken from the F2 region of the ionosphere,
  must be returned to the ground
• In order to collect valid data, the payload must
  be pointed to within 30 degrees of the satellite
  radial vector
• The camera payload must capture at least one
  daytime image of the US west coast the goal is
  to create an image archive map of the entire US.
• The formation flying experiment must be
  repeatable at least 3 times over an experimental
  period of two weeks
• At least 50 of the tether payload must be
  deployed the goal is 95

Vague
Operationally vague is an image of black
space OK?

• Bad examples
• Data must be returned to the ground promptly
• The camera payload must capture at least one
  image
• A magnetic torque rod control system must
  de-tumble the satellite within 3 hours
• The goal is to deploy at least 90 of the tether
  payload

Likely a system requirement
Only a goal no minimum success identified
8
Systems Design Process
Directly support mission requirements goals
System requirements Internal and External
Operations plan
Supports system requirements
Mission design
Subsystem requirements
Operational requirements
Defines design details
Component Requirements
Operational Constraints
Orbital environment

• Bottom Line
• Standardized top-down thinking process
• Can justify defend decisions (know the
  assumptions!!)
• ALL team members must buy in
• Write a formal requirements document!!

• Interface requirements
• electrical
• mechanical
• software

9
Systems Engineering Practices
Set up a plan for each of these EARLY!

• Documentation Organization
• Materials Lists
• CAD drawings
• Safety documents
• Interface controls
• Configuration management

• Design Budgets
• Power
• Memory/data
• Communications
• Mass
• Other resources

• Acquisition strategies
• Beg
• Borrow
• Steal
• Purchase

• Identify design drivers
• Cost
• Schedule
• Performance

• Interface Control
• Harness Connectors
• Structural connections
• Software protocols signal processing

Risk reduction strategies
10
Personnel Management
Each team will have a unique pool of available
talent
Educational opportunity learn to look for,
identify, and utilize your teams unique skills

• Common High-Value Skills
• Ace programmers
• Machinists
• Electronic board designers
• CAD/ORCAD wizards
• Communications equipment designer
• Master solderer
• HAM radio operator
• Documentation expert/librarian skills

Know what expertise is in-house and what you
need to farm out

• Find a new student with desired skills
• Cooperation with on-campus academic / research
  groups
• Off-campus volunteers
• Hire professional / purchase skills

11
Maintaining Team Performance
Educational opportunity practice leadership,
communications, and resource management skills

• How to deal with non-performers
• No such thing everyone has something to
  contribute
• Make sure theyre not in over their head
• Use buddy system

• How to mitigate screw-ups
• In the lab clearly label equipment and
  procedures!
• Administrative identify back-up plans / vendors
  in advance
• Use buddy system

• How to deal with team transition student
  roll-overs
• Good, organized documentation, mission
  requirements
• Strong administrative support
• Plan ahead, and keep on schedule!!!

12
Getting Started Warnings!
Guess what you are already behind!!
Two years may seem like a long time, but

• Program set-up dont spin your wheels
• Agree to a mission statement and requirements
  quickly (easier if you have pre-determined
  science objectives)
• Think small and simple to start this will be
  difficult enough as is
• Assess team skills early

• Beware of
• Summer breaks
• Post-vacation malaise
• Exam weeks

• Common engineering effort pits
• CPU interfacing
• Writing and testing software
• Debugging electronics
• Communications electronics (design AND
  fabrication)
• Thermal analysis
• Trying to organize a poor documentation plan

13
Miscellaneous Thoughts

• Do you have good lab management processes?
• Where are you going to build your satellite?
• How do you plan to conduct mission ops?
• Are students aware of the local acquisition
  processes?
• How will you objectively review your work
  internally?
• Documentation means taking pictures, too!!!
• Bigger teams require better management skills

Follow-up questions or comments? Email
brian.engberg_at_kirtland.af.mil Phone (505)
853-2349