PURDUE PLM CENTER FACULTY FELLOW PROJECT UPDATE · Solar Array 1. Solar Array 2. Battery. Power...

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

Presenter

Presentation Notes

A brief overview of what we talked about in the last presentation. Last presentation dealt with the ‘green’ region.

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

Presenter

Presentation Notes

A brief review about metrics guidebook

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

Presenter

Presentation Notes

This slide just gives example of Orsted satellite analysis from case studies we talked about in the last presentation. Not to spend more than 30 seconds on this slide.

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


Perf

orm

anc

e

Complexity

Model Based Design

Requirements

Manufacturing

Presenter

Presentation Notes

The ‘green’ region shows the areas we are focusing now.�Starting from requirements to formalized design language (i.e. SysML) and how it feeds into design space exploration and design simulation for V&V

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

Presenter

Presentation Notes

The SysML is serving two important uses: Design Space Exploration – by the complexity assessment of various architectures generated by making simple changes to SysML representations Design Simulation – enabling the design simulation with the help of link to in-house ABM tool (DAF). The SysML representations are connected to DAF using MagicDraw software,

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

Presenter

Presentation Notes

There are two types of network sets in SysML: Logical and Physical.� This slide gives an example of a Logical Network for a satellite system scanning and tracking a target using sensors and control groups. Logical network shows the exchange of information between systems. It explains what information is being transferred between systems (data and command in this case)

Physical Network

Presenter

Presentation Notes

This is the Physical Network for the same system as in previous slide. A physical network shows the physical connectivity between individual systems. It shows over which physical paths the information is transferred. (Radio Frequency over here)

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


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»


allocatedFrom«activity»DetectLosOfTraction

d1:TractionDetector


m1:BrakeModulator



satisfies«requirement»Anti-LockPerformance






SatisfiedBy«block»Anti-LockController



«deriveReqt»


allocatedFrom«activity»DetectLosOf Traction

d1:TractionDetector

valuesDutyCycle: Percentage


m1:BrakeModulator



satisfies«requirement»Anti-LockPerformance




VerifiedBy«interaction»MinimumStoppingDistance



SatisfiedBy«block»Anti-LockController



«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.






[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:






[f = (tf*bf)*(1-tl)]

tf: bf:tl:

f:

F:

m:

a:a:

v:

v:

x:

v.Position:









[f = (tf*bf)*(1-tl)]

tf: bf:tl:

f:

F:

m:

a:a:

v:

v:

x:

v.Position:









[f = (tf*bf)*(1-tl)]

tf: bf:tl:

f:

F:

m:

a:a:

v:

v:

x:

v.Position:




Monte Carlo DAF Simulation

Performance Metrics

1. Structure 2. Behavior

3. Requirements 4. Parametrics

Presenter

Presentation Notes

This animation explains the complete workflow of SysML and where DAF simulation comes in. We start with four basic viewpoints of SysML: Structural which defines the elements of the system Behavioral explains the interaction, architecture in the system Requirements viewpoint works as a requirement management tool. It also gives an option to create generic requirement boxes which can be modified as per the application. Parametric viewpoint explains constraints via logical and mathematical expressions We allocate the components of Behavior box (architecture) to that of system elements in the Structure box. Next, we set the requirements for different elements using the requirement viewpoint. After setting up the requirements, the parametric model containing the governing equations is created and the system is simulated for the values of inputs. The simulation gives out output values of dependent variables and it is verified whether the requirements are satisfied. We will use DAF here to do the Monte Carlo simulation by changing the input values to the system and thus producing a number of simulated results. All the result values will be verified using the requirement box. The values for performance metrics can then be calculated by applying the statistical analysis on the Monte Carlo simulation.

Thank You

SysML Basics

Presenter

Presentation Notes

The next 3 slides give a brief overview of SysML. This slide explains four different viewpoints of SysML to define the system Structural deals with definition of elements of the system Behavioral viewpoint explains the interaction, architecture in the system Requirements viewpoint works as a requirement management tool. It also gives an option to create generic requirement boxes which can be modified as per the application. Parametric viewpoint explains constraints via logical and mathematical expressions The structural viewpoint defines the basic elements (or components) of our system. In defining the In the behavior viewpoint, we describe the architecture and the interaction between the elements. The

Complexity enabled 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

PURDUE PLM CENTER FACULTY FELLOW PROJECT UPDATE · Solar Array 1. Solar Array 2. Battery. Power...

Documents

Transcript of PURDUE PLM CENTER FACULTY FELLOW PROJECT UPDATE · Solar Array 1. Solar Array 2. Battery. Power...