personal introduction n.
Skip this Video
Download Presentation
Personal Introduction

Loading in 2 Seconds...

play fullscreen
1 / 14

Personal Introduction - PowerPoint PPT Presentation

  • Uploaded on

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:

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Personal Introduction' - fuller-santiago

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
personal introduction
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; I am currently Chief Engineer of AFRL/VSSL, working on programs to deliver space-based laser communications technology

I also continue to provide support to the University Nanosat Program

university satellite programs
University Satellite Programs
  • So you want to build a satellite?
  • There’s 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
  • You have been selected for a competition, but more importantly, you have been selected toreceive an education!

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
keys to success
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 technical/engineering roadblocks!

leadership roles
Leadership Roles

Good communication paths are critical!


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

organized requirements
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


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


System / Operational Requirements

CONOPs plan

Subsystem Requirements

mission statements
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 Earth’s 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 Earth’s 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!!!!

mission goals and requirements
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%


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

flowing down requirements
Flowing Down Requirements

Directly support mission requirements & goals

System requirements

Internal and External

Operational Requirements

Supports system requirements

Mission design

Subsystem requirements

Concept of Operations Plan

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
systems engineering process
Systems Engineering Process

Requirements Loop



Understand the requirements and how they affect the way in which the system must function.

Design Loop



Identify a feasible solution that functions in a way that meets the requirements


Defining & understanding the requirements is critical


Many people try to start here (big mistake)

Verification Loop

Show that the synthesized design meets all requirements

Systems Analysis

& Control

Synthesis Control Loop

Identify and employ “control mechanisms” that manage configuration, interfaces, data products, technology insertion, and program risk

systems engineering practices
Systems Engineering Practices

Set up a plan for each of these EARLY!

  • Documentation Organization
    • Requirements (!!)
    • 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 mitigation strategies!

personnel management
Personnel Management

Each team will have a unique pool of available talent

Educational opportunity: learn to look for, identify, and utilize your team’s 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
maintaining team performance
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 they’re not “in over their head”
  • Are they working on an aspect that interests them?
  • 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!!!
getting started warnings


Getting Started – Warnings!

Guess what – you are already behind!!

Two years may seem like a long time, but…

  • Program set-up: don’t “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
miscellaneous thoughts
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: Phone: (505) 853-2349