Transcript Team Name

Team Name
Preliminary Design Review
University/Institution
Team Members
Date
RockSat-C 2012
PDR
1
User Notes
• You can reformat this to fit your design, but
be sure to cover at least the information
requested on the following slides
• This template contains all of the
information you are required to convey at
the PDR level. If you have questions, please
don’t hesitate to contact me directly:
[email protected]
720-314-3552
RockSat-C 2012
PDR
2
User Notes
• This template is based on an example
mission to show the level of detail
needed for your “preliminary design”
RockSat-C 2012
PDR
3
Purpose of PDR
• Confirm that:
gnurf.net
– Science objectives and required
system performance have been
translated into verifiable
requirements
– Payload Design: to specifications from
requirements, can be met through
proposed design (trade studies)
– Project risks have been identified, and
mitigation plans exist
– Project management plan is adequate
to meet schedule and budget
– Project is at a level to proceed to
prototyping of high risk items
RockSat-C 2012
PDR
4
PDR Presentation Content
• Section 1: Mission Overview
–
–
–
–
–
Mission Overview
Organizational Chart
Theory and Concepts
Concept of Operations
Expected Results
• Section 2: System Overview
–
–
–
–
–
–
Subsystem Definitions
Critical Interfaces (ICDs?)
System Level Block Diagram
System/Project Level Requirement Verification Plan
User Guide Compliance
Sharing Logistics
RockSat-C 2012
PDR
5
PDR Presentation Contents
• Section 3: Subsystem Design
– Subsystem A (SSA) (i.e. EPS)
• SSA Block Diagram
• SSA Key Trade Studies (1 – 2?)
• Subsystem Risk Matrix/Mitigation
– Subsystem B (SSB) (i.e. STR)
jessicaswanson.com
• SSA Block Diagram
• SSA Key Trade Studies (1 – 2?)
• Subsystem Risk Matrix/Mitigation
– Etc., Etc…
RockSat-C 2012
PDR
6
PDR Presentation Contents
• Section 4: Prototyping Plan
– Item “A” to be Prototyped
– Item “B” to be Prototyped
– Etc., Etc…
• Section 5: Project Management Plan
–
–
–
–
–
User’s Guide Compliance, Sharing
Org Chart
Schedule
Work Breakdown Structure
Budget
RockSat-C 2012
PDR
7
Mission Overview
Name of Presenter
RockSat-C 2012
PDR
8
Mission Overview
• Mission statement
• Break mission statement down into your
overall mission requirements
• What do you expect to discover or prove?
• Who will this benefit/what will your
data be used for?
RockSat-C 2012
PDR
9
Theory and Concepts
• Give a brief overview of the underlying
science concepts and theory
• What other research has been performed
in the past?
– Results?
RockSat-C 2012
PDR
10
Concept of Operations
• Based on science objectives, diagram of
what the payload will be doing during
flight, highlights areas of interest
• Example on following slide
RockSat-C 2012
PDR
11
Example ConOps
Altitude
t ≈ 1.7 min
Altitude: 95 km
t ≈ 4.0 min
Event B Occurs
Altitude: 95 km
t ≈ 1.3 min
Apogee
Altitude: 75 km
t ≈ 2.8 min
Event A Occurs
Altitude: ≈115 km
Event C Occurs
t ≈ 4.5 min
Altitude: 75 km
Event D Occurs
End of Orion Burn
t ≈ 0.6 min
t ≈ 5.5 min
Altitude: 52 km
t = 0 min
Chute Deploys
-G switch triggered
t ≈ 15 min
-All systems on
Splash Down
-Begin data collection
RockSat-C 2012
PDR
Expected Results
• This is vital in showing you understand
the science concepts
• Go over what you expect to find
– Ex. What wavelengths do you expect to see?
How many particles do you expect to
measure? How well do you expect the spin
stabilizer to work (settling time?)? How
many counts of radiation? etc
RockSat-C 2012
PDR
13
System Overview
Name of Presenter
RockSat-C 2012
PDR
14
System Level Block Diagram
• Show a full system of your subsystems, and the connections between them
STR
EPS
WFF Power
Interface
Buck
Converter
uController
Boost
Converter
Legend
Wallops PT
Interfaces
Data/
Control
Motor
Controller
PM
High
Voltage
DEP
Low
Voltage
Photomultiplier
WFF Telem.
Interface
RockSat-C 2012
PDR
15
System Design – Physical Model
Battery
Accelerometer
WFF Door
Piece
MEPO
Board
Mounting
Flange
Detector
AVR
G-Switch
Board
RockSat-C 2012
PDR
16
That was a BAD PHYSICAL MODEL!
• Why? Because you must have
DIMENSIONS and UNITS!
• Remember, this is a preliminary design,
so the design doesn’t have to be perfect
or final
– But still have labels, dimensions, and units
RockSat-C 2012
PDR
17
Design in Canister (preliminary)
Where are the
dimensions?!
RockSat-C 2012
PDR
18
System Concept of Operations
• Here, include a diagram and a step by step
of your data collection process, or major
activities happening in your payload
– If you are collecting data, show/discuss when
the data will be available, how it’s collected,
and where it gets sent
– If you have moving parts, be sure to include a
simplified timeline of how things are
happening along with the data collection
• This slide must be included
RockSat-C 2012
PDR
19
Critical Interfaces
• At the PDR level you should at minimum identify critical interfaces.
The following is an example of types of interfaces you might have, and
how the interface between two systems might be designed
Interface Name
Brief Description
Potential Solution
EPS/STR
The electrical power system boards will need to mount to the
RockSat-X deck to fix them rigidly to the launch vehicle. The
connection should be sufficient to survive 20Gs in the thrust
axis and 10 Gs in the lateral axes. Buckling is a key failure
mode.
Heritage shows that stainless steel or
aluminum stand-offs work well. Sizes and
numbers required will be determined by CDR.
PM/STR
The photomultiplier will need to mount to the RockSat-X deck
rigidly. The connection should be sufficient to survive 20Gs in
the thrust axis and 10 Gs in the lateral axes. Most likely, the
PM will hang, and the supports will be in tension.
A spring and damper support will need to be
developed. The system should decrease the
overall amplitude of vibration no less than
50%.
The deployment mechanism must rigidly connect to the
RockSat-X deck. The actuator has pre-drilled and tapped 8-32
mounts.
8-32 cap head screws will mount the
deployment mechanism to the plate. The
screws will come through the bottom of the
plate to mate with the DEP system.
The deployment mechanism has a standard, male RS-232
DB-9 connector to interface to a motor controller (male), which
is provided with the DEP mechanism. The motor controller will
be controlled by EPS.
A standard, serial cable with female DB-9
connector on both ends will connect the motor
controller to the DEP mechanism. The motor
controller to EPS system interface is yet to be
determined.
The photomultiplier requires 800V DC and outputs pulses at
TTL levels. The PM also requires a ground connection.
A TBD 2 pin power connector (insulated) will
connect the EPS board to the PM. A separate,
TBD connector will transmit the pulse train to
the asynchronous line at a TBD Baud rate.
DEP/STR
DEP/EPS
PM/EPS
RockSat-C 2012
PDR
20
Requirement Verification
• At the PDR level, highlight the most
critical project/system requirements and
determine how you will VERIFY these
requirements
– This starts the process of test planning
• Verification: did you build the thing right?
– Validation: did you build the right thing – we
won’t focus too much on validation, because it
is more of a customer consideration
RockSat-C 2012
PDR
21
Requirement Verification Example Table
Requirement
They deploable boom shall deploy to a
height of no more than 12”
The boom shall extend to the full 12”
height in less than 5 seconds from a
horizontal position.
The full system shall fit on a single
RockSat-X deck
The sytem shall survive the vibration
characteristics prescribed by the RockSatX program.
Verification Method
Description
Demonstration
Boom will be expanded to full length in the
upright position to verify it doesn’t exceed
12”
Analysis
Inspection
Test
RockSat-C 2012
PDR
The system’s dynamical characteristics
will be derived from SolidWorks, and
available torques will yield minimum
response time.
Visual inspection will verify this
requirement
The system will be subjected to these
vibration loads in June during testing
week.
22
Why do we care about requirements?
• At this point, I will
be checking to make
sure you have a
good set of
requirements to
define your project
• This comic is an
entertaining, but
accurate, depiction
of what can happen
with a project that
is not well defined,
managed, and
documented
http://www.codinghorror.com/blog/2005/03/on-software-engineering.html
RockSat-C 2012
PDR
23
Subsystem Design
Name of Subsystem
*You will have several subsystems*
Name of Presenter
RockSat-C 2012
PDR
24
Subsystem Design Section
• This section is where you explain how each
subsystem was designed
• Discuss how you researched components that
would meet your requirements
– Show trade studies if necessary, and if you show
them, be prepared to explain the scoring and
categories
• The most important part is explaining how you
reached your major design decisions in each
subsystem
• After explaining components, discuss any risks
associated with this subsystem
RockSat-C 2012
PDR
25
Subsystem Overview – Block Diagram
• Show your subsystems, now with more detail inside
the boxes, and the connections between them
RockSat-C 2012
PDR
26
EPS: Block Diagram
• Show the subsystem block diagram with primary component choices
highlighted.
Legend
Data/
Control
Power
RockSat-C 2012
PDR
27
EPS: Trade Studies
• Show rationale for you choices in components. You basically weigh your
options against your requirements and what each component can offer.
Don’t forget things like: availability, cost, and prior knowledge. I
recommend an online search for examples if you are unsure, or contact me.
µController
XMega
ATMega 32 L
Cost
8
10
Availability
10
10
Clock Speed
10
5
A/D Converters
9
5
Programming
Language
8
8
Average:
9
7.6
• You should have completed a
trade study for each block, but you
only need to present the 2-3 most
important.
• Numbers are relatively subjective,
but 10 should represent a perfect
fit, 5 will work, but is not
desirable, and 0 does NOT meet
expectations.
• The component with the highest
average should drive your choice
for design.
RockSat-C 2012
PDR
28
EPS: Risk Matrix
EPS.RSK.1
Consequence
EPS.RSK.4
EPS.RSK.2
EPS.RSK.3
• Risks for the subsystem under
discussion should be documented
here
• The horizontal represents the
likelihood of a risk, the vertical is
the corresponding consequence.
• Risks placement should help drive
mitigation priority
Possibility
EPS.RSK.1: Mission objectives aren’t met IF microcontroller fails in-flight
EPS.RSK.2: Mission objectives aren’t met IF a suitable motor controller cannot
be procured
EPS.RSK.3: The EPS system can’t survive launch conditions, and the mission
objectives aren’t met
EPS.RSK.4: A strain will be put on the power budget IF flying monkeys delay the
launch by an hour
RockSat-C 2012
PDR
29
Writing Risks – a note
• When you write a risk, you are writing
about the bad thing that might result, NOT
the cause
– Ex: “Risk 1: There might be one+ month delay
in obtaining our science instrument” – not
quite. This is the cause. The RISK is what this
might do to your project, like delay testing,
integration, schedule, etc, so you could write
“Risk 1: The integration schedule will slip due
to delays in procuring the science instrument”
RockSat-C 2012
PDR
30
Prototyping Plan
Name of Presenter
RockSat-C 2012
PDR
31
Prototyping Section
• The purpose of this section is to help you
identify what components/connections
might need testing before you can say
with confidence that you want
something in your final design
• Not everything must be prototyped (you
don’t have time)
• Prototypes are usually used to address
risks
RockSat-C 2012
PDR
32
Prototyping Plan
• What will you build/test between now and CDR to mitigate risks?
Risk/Concern
STR
Concern about mounting the
PM to the deck has been
expressed (Risk: jeopardize
the mission objectives)
Action
Prototype this interface
and verify the fit with
the PM
PM
Concerns about testing the
PM on the ground have
been expressed
Develop a test plan
and verify it with LASP
mentors
DEP
Mounting the probe to the end
of the boom will present a
significant challenge
Mount a test probe and
verify structural rigidity
EPS
The functionality of the
microcontoller board needs
to be verified by CDR
Prototype the micro
board on a bread board
to verify functionality
RockSat-C 2012
PDR
33
Project Management Plan
Name of Presenter
RockSat-C 2012
PDR
34
RockSat-C 2012 User’s Guide Compliance
• Rough Order of Magnitude mass
estimate
– Initial masses of major components,
sensors, structural pieces
– Start thinking about BALLAST
• CG – predicted CG based on your design
• Are you using high voltage
– How are the schematics/safety coming
along?
• Are you using any ports? How will you
interface with them? Are you sharing an
atmospheric port? – you may not know
some of these at this time, which is fine
RockSat-C 2012
PDR
35
Sharing Logistics – if applicable
• If known:
• Who are you sharing with?
– Summary of your partner’s
mission (1 line)
• Plan for collaboration
– How do you communicate?
– How will you share designs
(solidworks, any actual fit
checks before next June)?
• Structural interface – will you
be joining with standoffs or
something else (again, be
wary of clearance)?
RockSat-C 2012
PDR
grandpmr.com
36
Organizational Chart
Project Manager
Shawn Carroll
System Engineer
Emily Logan
Faculty Advisor
Chris Koehler
CFO
Shawn Carroll
Safety Engineer
Chris Koehler
Faculty Advisory
Riley Pack
Sponsor
LASP
Testing Lead
Jessica Brown
EPS
David Ferguson
Riley Pack
STR
Tyler Murphy
Aaron Russert
DEP
Aaron Russert
Shawn Carroll
PM
Kirstyn Johnson
Elliott Richerson
• Please turn your organization from CoDR into an official chart
• What subsystems do you have?
• Who works on each subsystem?
– Leads?
• Don’t forget faculty advisor/sponsor(s)
RockSat-C 2012
PDR
37
Schedule
• What are the major milestones for your project?
• (i.e. when will things be prototyped?)
• CDR
• When will you begin procuring hardware?
• Start thinking all the way to the end of the project!
• Rough integration and testing schedule in the spring
• Etc, etc, etc
schedule
• Format:
• Gant charts
• Excel spreadsheet
• Simple list
• Whatever works for you!
Don’t let the schedule
sneak up on you!
RockSat-C 2012
PDR
38
WBS
• Present a very top-level work break down schedule
• One can look up the tree for large scope goals
• One can look down the tree for dependencies
• Help each subsystem “see” the path ahead
• Based on the schedule and requirements
PMP
EPS
STR
PM
DEP
•Obtain PM from LASP
•Trade Studies
•Trade Studies
•Obtain PM from LASP
•Obtain PM from LASP
•EEF Proposal for
funding
•…
•…
•Schematics
•Order Materials
•EEF Proposal for
funding
•Schematic Review
•EEF Proposal for
funding
•Work Request Into
Shop
•…
•…
•…
•…
•ICDs
•First Revision of
Boards
•…
•…
•…
•…
RockSat-C 2012
PDR
39
Budget
• Present a very top-level budget (not nut and bolt level)
• A simple Excel spreadsheet will do
• Most important factor is LEAD TIME
• Simply to ensure that at this preliminary stage you aren’t over budget
• It is suggested that you add in at least a 25% margin at this point
Margin:
0.25
Budget:
$1,300.00
ExampleSat
Item
Supplier
Estimated, Specific Cost Number Required
Motor Controller
DigiKey
$150.00
PM
LASP
$0.00
Microcontroller
DigiKey
$18.00
Printed Circuit Boards Advanced Circuits
$33.00
Misc. Electronics (R,L,C) DigiKey
$80.00
Boom Material
onlinemetals.com
$40.00
Probe
LASP
$0.00
Testing Materials
???
$200.00
RockSat-C 2012
PDR
Last Update:
Toal Cost
2
1
3
3
3
2
1
1
9/30/2010 11:50
Notes
$300.00 1 for testing
$0.00 LASP mentor deserves shirt
$54.00 3 board revs
$99.00 3 board revs
$240.00 3 board revs
$80.00 1 test article
$0.00
$200.00 Estimated cost to test system
Total (no margin):
Total (w/ margin):
$973.00
$1,216.25
40
Conclusion
• Summarize your main action items to
get done before CDR
• Issues, concerns, any questions
RockSat-C 2012
PDR
41