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; 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

2. 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

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 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 / Operational Requirements CONOPs plan 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 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!!!!

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. 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

9. Systems Engineering Process Requirements Loop Requirements Analysis Understand the requirements and how they affect the way in which the system must function. Design Loop Functional Allocation Identify a feasible solution that functions in a way that meets the requirements Tip: START HERE Defining & understanding the requirements is critical Synthesis 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

10. 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!

11. 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

12. 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!!!

13. ! 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

14. 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@kirtland.af.mil Phone: (505) 853-2349