administratively controlled information. introduction and background this is going to be hard –...
TRANSCRIPT
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!
