Upload
ginger-gibbs
View
217
Download
2
Tags:
Embed Size (px)
Citation preview
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!