purdue plm center faculty fellow project update · solar array 1. solar array 2. battery. power...
TRANSCRIPT
Daniel DeLaurentisDirector, Center for Integrated Systems in Aerospace
Associate Professor, School of Aeronautics and Astronautics
PURDUE PLM CENTER FACULTY FELLOW PROJECT UPDATE
Requirements
Design
Analysis
Manuf.Supply Chain
Sustain./MRO
Recycle
Process
DataPeople
Tools
Synopsis
ProductDefinition
What: Demonstrate the effectiveness of next generation design tools and integrate them with the early-phase PLM processes.
Why: Next-Gen design tools and model-based methods are expected to reduce cost and development time by effective complexity management, efficient design space exploration and designing products that are correct by construction against requirements.
Next Generation Design Process: Last Year’s Focus
Verification and Validation
Stochastic Formal Verification
.
.
Metrics
Design Space Exploration
Perf
orm
anc
e
Complexity
Model Based Design
Requirements
Manufacturing
SCOPE: Towards a Metrics Guidebook
Metrics Guidebook
Diff
eren
t Lev
els o
f Abs
trac
tion Design Manufacturing
High Level
Low Level Information theoretic metrics
Network theoretic metrics
Data
Design
Cost
• Cost-Complexity relationship• Which subsystems are complex• Integration with Design Space
Exploration Tools
Type of Data depends on what metric is chosen
Case StudyNetwork Theoretic Metric Example
Antenna 1
Diplexer 1Tranceiver 1Softw
areEncod
er
Solar Array 1
Solar Array 2
Battery
Power Regulator 3
Power Regulator 4
Power Regulator 5
Power Regulator 6
Software
Distributor
Current Sensor
Power Regulator 2
Power Regulator 1
Power Regulator 7
Power Regulator 8
GPS 1
Sun
Sensor 1
Torquer1
Software
Star
Tracke
r
GPS
Sun
Sensor 2
Sun
Sensor 5
Sun
Sensor 3
Sun
Sensor 4
Sun
Sensor 6
Torquer2
Torquer3
GPS2
Current Sensor
Star Imager Magnetometer 2Magnetometer 1 Particle Dectector
Memory
MUC 1
MUC 2
Type of interactionBlue= information , Green= Force Red=Energy Orange=Matter
Structural Graph for Orsted
Case Study with Network theoretic metric
Orsted
HETE
Clementine
010203040506070
5000 10000 15000D
esig
n C
ost-L
aunc
h C
ost
(FY
08$K
*100
0)Coupling Complexity (Ccc)
Cost vs Complexity
Cost vs. Complexity for three spacecraft
0
2000
4000
6000
8000
10000
12000
14000
16000
Orsted HETE Clementine
Complexity of Subsystems
System ComplexityIntegrationPowerControls (ADCS)Communication (Comm.)Data Handling (CDH)
Key Insights
Identified Cost-Complexity correlationfor spacecraft case study.
Formulated how this correlation can beused to analyze the impact of designchanges on integration cost.
Developed an algorithm for moduleidentification which minimizesintegration complexity.
Demonstrated how complexity can beused with other non-traditional measures(such as flexibility and robustness) toguide decision making in a design spaceexploration environment.
Companies identified product-variantsass key focus area (vice brand newproduct)
Small Satellite Design
Full-Size Baja Buggy design
This Year’s Focus: Connecting Models to Tools
Verification and Validation
Stochastic Formal Verification
.
.
Metrics
Design Space Exploration
Perf
orm
anc
e
Complexity
Model Based Design
Requirements
Manufacturing
Enabling the ‘Digital Thread’Exploring Model-Based Representations
• Design Space Exploration– Test complexity metrics and
assessment using SysML representations
• Design Simulation– Connecting SysML to in-
house ABM tool (Discrete Agent Framework, DAF)
Magic Draw• SysML representations• ParaMagic plugin
MATLAB• DAF• Simulink
Requirements
Design
Analysis
Manuf.Supply Chain
Sustain./MRO
Recycle
Process
DataPeople
Tools
ProductDefinition
Systems Modeling Language (SysML)• Four set of viewpoints to define the system
– Structural – definition of elements– Behavioral – interaction, architecture– Requirements – requirement management (checklist)– Parametric – constraints via logical, mathematical expressions
• Network sets– Logical
• Exchange of information between systems• What information is transferred between systems
– Physical• Connectivity of systems• Over which physical paths the information is transferred
Logical Network
Physical Network
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
c
a:a:
v:
v:
x:
SysML Workflow
ibd [block] Anti-LockController [Internal Block Diagram]
d1:Traction Detector
m1:Brake Modulator
c1:modulator interface
ibd [block] Anti-LockController [Internal Block Diagram]
allocatedFrom«activity»DetectLosOfTraction
d1:TractionDetector
allocatedFrom «activity»Modulate BrakingForce
m1:BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
act PreventLockup [Activity Diagram]
DetectLossOf Traction
Modulate BrakingForceTractionLoss:
act PreventLockup [Swimlane Diagram]
«allocate»:TractionDetector
«allocate»:BrakeModulator
allocatedTo«connector»c1:modulatorInterface
DetectLossOf Traction
Modulate BrakingForceTractionLoss:
req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements]
Braking Subsystem Specification
Vehicle System Specification
id=“102”text=”The vehicle shall stop from 60 mph within 150 ft on a clean dry surface.”
«requirement»StoppingDistance
id=”337"text=”Braking subsystem shall prevent wheel lockup under all braking conditions.”
«requirement»Anti-LockPerformance
«deriveReqt»
ibd [block] Anti-LockController [Internal Block Diagram]
allocatedFrom«activity»DetectLosOfTraction
d1:TractionDetector
allocatedFrom «activity»Modulate BrakingForce
m1:BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
satisfies«requirement»Anti-LockPerformance
req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements]
Braking Subsystem Specification
Vehicle System Specification
id=“102”text=”The vehicle shall stop from 60 mph within 150 ft on a clean dry surface.”
«requirement»StoppingDistance
SatisfiedBy«block»Anti-LockController
id=”337"text=”Braking subsystem shall prevent wheel lockup under all braking conditions.”
«requirement»Anti-LockPerformance
«deriveReqt»
ibd [block] Anti-LockController [Internal Block Diagram]
allocatedFrom«activity»DetectLosOf Traction
d1:TractionDetector
valuesDutyCycle: Percentage
allocatedFrom «activity»Modulate BrakingForce
m1:BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
satisfies«requirement»Anti-LockPerformance
req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements]
Braking Subsystem Specification
Vehicle System Specification
VerifiedBy«interaction»MinimumStoppingDistance
id=“102”text=”The vehicle shall stop from 60 mph within 150 ft on a clean dry surface.”
«requirement»StoppingDistance
SatisfiedBy«block»Anti-LockController
id=”337"text=”Braking subsystem shall prevent wheel lockup under all braking conditions.”
«requirement»Anti-LockPerformance
«deriveReqt»
satisfy
Based on Hause, Matthew C , and F. Thom. 2008. "An Integrated MDA Approach with SysML and UML." In UML&AADL 2008 Belfast, Northern Ireland: artist.
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
m:
a:a:
v:
v:
x:
v.Position:
v.Weight:v.chassis.tire.Friction:
v.brake.abs.m1.DutyCycle:
v.brake.rotor.BrakingForce:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
m:
a:a:
v:
v:
x:
v.Position:
v.Weight:v.chassis.tire.Friction:
v.brake.abs.m1.DutyCycle:
v.brake.rotor.BrakingForce:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
m:
a:a:
v:
v:
x:
v.Position:
v.Weight:v.chassis.tire.Friction:
v.brake.abs.m1.DutyCycle:
v.brake.rotor.BrakingForce:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx/dt]
:BrakingForceEquation
[f = (tf*bf)*(1-tl)]
tf: bf:tl:
f:
F:
m:
a:a:
v:
v:
x:
v.Position:
v.Weight:v.chassis.tire.Friction:
v.brake.abs.m1.DutyCycle:
v.brake.rotor.BrakingForce:
Monte Carlo DAF Simulation
Performance Metrics
1. Structure 2. Behavior
3. Requirements 4. Parametrics
Thank You
SysML Basics
Complexity enabled design-space exploration
Design Space Exploration
Good Designs
Domain Knowledge
• Common features of good and bad designs
• Complexity threshold
EXPERT SYSTEM
PreliminaryExploration
Design promotion scheme
Design Generator
Component Library
Requirements
Results for Fractionated Satellite Design
Complexity Enabled Design Space Exploration Framework
Case Study with Information Theoretic Metric
Q: Joint distribution of quantities of interestC(Q) : Complexity of the systemH(Q): Differential entropy of Q
MetricThis metric measures the potential ofthe system to show unexpectedbehavior in the quantities of interest.
Adder Circuit
Case Study
Case 2: We know V1 and V2 to be independent uniformly distributed between 0 and 5V
V0 will have a triangular distribution with complexity of 3.39
Case 1: Assume V1 and V2 to jointly normal distributed.
Complexity=5.3Less Information more complexity
More Information reduces complexity
For additional details see the attached documentation
Case Study with Information Theoretic Metric
Data Required1. Quantities of interest (Performance, Cost etc. )2. Functional relationship between Quantities of interest
and input variables.3. Uncertainty in variables .
Things that can be measured1. Complexity associated with uncertainty. 2. Possibility of system to show unexpected behavior.
Case Study with Network theoretic metric
Case Study
Antenna 1
Diplexer 1
Tranceiver 1
Software
Encoder
Solar
Array 1
Solar
Array 2
Battery
Power Regulator 3
Power Regulator 4
Power Regulator 5
Power Regulator 6
Softwar
e
Distributor
Curren
t Sensor
Power Regulator 2
Power Regulator 1
Power Regulator 7
Power Regulator 8
GPS 1
Sun Sensor 1 T
orquer1
Software
Star TrackerGPS
Sun Sensor 2
Sun Sensor 5
Sun Sensor 3
Sun Sensor 4
Sun Sensor 6
Torquer2Torquer3
GPS2
Curren
t Sensor
Star Imag
er
Magnetomete
r 2
Magnetomete
r 1
Particle
Dectector
Memory
MUC 1
MUC 2
Type of interactionBlue= information , Green= Force Red=Energy Orange=Matter
Communication
Electrical Power System
Command and Data Handling
Attitude Determination and Control Subsystem
Payload
Structural Graph for Orsted
TIMELINEPhase 1- Component 1
Month 1: Initial calls with PLM Center partners to identify priorities and revisit goals.
Month 2-3: Identifying available data flows, to guide choosing the appropriate metrics.
Month 4-5: Developing the ‘Metrics Guidebook’ demonstrating it on the case study.
Month 6: Writing and Publishing; Mid-project WEBEX presentation.
Phase 2- Component 2
Month 1: Understand and summarize design exploration tools used in the industry
Month 2-3: Identifying how to integrate the tool with PLM tools.
Month 4-5: Demonstrating the process on the case study.
Month 6: Writing and Publishing
Where we ended
• Next Generation Design Process– Model based design
• Metrics Guidebook• Information Theoretic Metric
– Circuit case study
• Network Theoretic Metric– Spacecraft case study– Baja buggy case study