Administratively Controlled Information

Thursday, 8th January, 2015James Chartres

Millennium Engineering and Integration Services

Systems Engineering for Low Cost Missions - Lessons Learned

Introduction and Background

• This is going to be hard – but also rewarding• Survive beyond LEO

• Navigation

• Communication

• Things to consider - there is no magic here

• Back to Basics

• Planning

• Requirements – Isn’t a dirty word

• Systems Engineering Processes – It all depends

• Perils and Pitfalls

• Design, Develop, Integrate, Test, Repeat

Back to Basics

• Systems Engineering

• Use “good” engineering practices

• Tailor your approach to size, scope and importance of the task

• Light and agile processes

• Mission success first

• Cutting corners or eliminating doesn’t save, it costs

• Leverage recent collaboration advancements

• Focus on testing

Planning – A little bit goes a long way

• Don’t just rush in

• The grab bag approach of sticking a bunch of parts together is difficult for space

• Small teams have limited resources

• Maximize resource use by planning ahead

• Always ask “What problem are you trying to solve?”

• Goals and Objectives

• Architecture and ConOps

• Only as much as needed

Requirements – Isn’t a dirty word

• Requirements – has a stigma – lets call it something different “Functions”, “Task”, “Do-majiga”

• What it really means is “What does it have to do?”

• Start from Goals and Objectives

• Concept of Operations

• Work out your functions

• Break them down to elements

• Only break them down as far as you need to define your product/work elements

• Only as many as you need – otherwise delete it• Rational – Why is it there? Does it need to be?

• How can your prove it

• Don’t create more to make the flow nice

Systems Engineering Processes – It all depends

• Only as much as you need and no more

• Processes are tools and only as useful as you use them they are there to assist not hinder

• Understand the benefits of processes and products

• Calculated Risk taking

• Configuration Management• Do you need it? How much?

• Make it useable and agile

• Leverage electronic documentation but understand the limitations

• Reviews = Free technical advice

Design, Develop, Integrate, Test, Repeat

• “What problem are you trying to solve?” - Keep your eye on it

• Concentrate your early efforts on the hard stuff

• Doesn’t have to be linear – first time doesn’t always work

• Build up functionality as you go

• Set interim milestones/tests

• Build for access, testability and replacement

• DevSats, FlatSats, EDUs, Flight Spares

• If items are cheap buy more than you think you need

• Spares are priceless if they save you time

• Focus on testing to verify/validate the system

• Test to what level? (system vs. subsystem vs. component vs. part)• Why are you doing the test?

• Focus on the core “Functions”

• Know the risks of delaying/eliminating your tests

Perils and Pitfalls – Learned the hard way

• Co-location / Communication• Everyone on the same page

• Know where your going and how everyone fits in

• Clearly define roles, responsibilities and accountability

• Focused multi-disciplinary teams

• Make the right technical decisions

• Hardware pedigree versus heritage

• Identify long-leads early

• Don’t forget support equipment and test software

• Automotive or industrial grade over commercial

Take Home Points

• What problem are you trying to solve?

• Concept of Operations and Architecture

• What does it need to do?

• Back to Basics - Use good practices

• System Engineering processes and products are tools

• Only as much as you need

• Think ahead and plan

• Design, Develop, Integrate, Test, Repeat

• Concentrate your early efforts on the hard stuff

• Have fun!

Questions

Contact Details:james.chartres@nasa.gov

Work: 650-604-3790