Optimizing for Responsive Space Design AIAA-RS-2004-5005 Terrance Yee

1. Optimizing for Responsive Space DesignAIAA-RS-2004-5005Terrance Yee

2. Introduction • MSI believes that small experimental satellites offer an opportunity to greatly shorten the development timeline compared to traditional spacecraft • Rapid design requires significant buy-in from the customer including coordination on risk approach, required documentation, and most importantly ground rules for generating requirements Streamlined Requirements, Design & Documentation Roadrunner Terra

3. Pre-Design Phase • Step 0: Mission Purpose, Team Selection, Contracting • Can be the most incompressible part of a responsive mission • Limited optimization due to regulations, fairness requirements • Alternate method: • Step 0.5: Define Core Purpose, Core Team and start with funding just for those • Gets basic system design started immediately • Allows long lead hardware to be purchased • Less cost efficient overall due to necessity of adjusting to late additions to the mission • Constrains later additions to work within framework of existing capability

4. Requirements • Minimizing schedule means setting an early baseline design that maximizes use of existing elements and short-lead time components • New payloads participate on a “capabilities driven” basis: they are only manifested if they can be accommodated within the capabilities of the existing design • Working within the framework of an existing design means that performance is often not specified: it is a function of the hardware/software available, not an independent variable to be chosen Max Return w/ Available System “Demonstration Objectives” “Requirements” Flexible CONOPS

5. Requirements Minimization • Don’t Duplicate ICD’s • Focus on primary functions, not performance • Ex. Pointing Modes not Control Accuracy • Don’t specify characteristics of hardware/software that has already been baselined • Less than 100 requirements for entire Roadrunner bus • Makes for quicker verification & test planning • Keeps focus on the key issues that you can affect

6. System Design Keys • Stick to what’s available immediately or sooner: • Parts built from in-house stock • Spares from other flight programs • COTS HW with short delivery times • Don’t optimize, don’t change • The first “tweak” costs a disproportionately large amount of time and money • Resist pressure to squeeze more utility by making a “minor” adjustment: you can’t build until you freeze the design • Use whole design solutions • A whole intact set eliminates the need for new interfaces • Use automated design tools

7. Excellence Ain’t Always Pretty • “Scrounging” and “Kluging” may make the marketing types cringe, but the soul of an elegant optimization for schedule often means making do with what’s at hand • Get over your biases and focus on what works best • Although it isn’t custom designed for your application, there is a distinct challenge in the art of choosing the best existing hardware to make a system work • New interfaces can be a killer, try to choose parts that work well together with minimal hardware changes • Mixing pedigrees of parts is OK, but don’t exceed the environments unless you can afford the testing • Quality comes from a good design and adequate testing • Where it’s from doesn’t matter as long as it works together

8. Documentation • Minimize, minimize, minimize • Keep the core essentials: ICD’s, Block Diagrams, Schematics, Drawings, Test Plans/Results, Budgets • Minimizing writing/reading frees up more time to talk face to face and work the real issues • Shorter schedules & tighter focus make it less likely things will be forgotten • Can rely more on informal documentation such as E-mail & notes providing that all key personnel participate • Centralized repository with universal access speeds coordination and upkeep of documents

9. Roadrunner Example

10. Communication/Organization • Small teams are much more efficient at communication • Requires the “right” people: smart, proactive, communicators • Empower team members to make decisions • Train them how and when to coordinate those decisions with others to keep the design consistent • Single organization, co-located is best, otherwise… • Structure contracts to allow technical solutions to be resolved dynamically without the need to renegotiate statements of work at each turn • Incentives for reaching mission objectives, not organizational deliverables • Keep SOW general and flexible enough to adapt as design matures, trust mission objective incentives to keep players honest

11. Conclusions • Optimizing for responsive design is not just about cutting schedule or adding more design resources, a different approach is required • Setting appropriate requirements and synthesizing solutions from a restricted set of available components is much more important that skill in customized design • Keeping the mission capabilities driven is a key enabler • Minimized documentation and small, empowered teams allow the process to be executed efficiently