1

Breaking Barriers between Product Lifecycle and Working Knowledge in Design

Karthik RamaniComputational Design Lab

School of Mechanical EngineeringSchool of Electrical and Computer Engineering (by

Courtesy)

2

Introduction• Design has no unique solution, so multiple alternatives can exist

(due to):– Several conflicting objectives– A requirement can be interpreted in several ways– Several solution principles / embodiments can achieve the same

function– Different composition of multiple disciplines (For example, in

mechatronic products)• Moreover, each of these solutions can be described in multiple

levels of detail and abstraction, for example– In the simplest case, an overall function broken into several simpler

functions and so on– Overall geometry (assembly) described in detail through component

models– The geometry of a single component can be described as a 2D sketch

or a 3D drawing….

3

Design Process

Activity Activity Activity

Design Problem

Process

Solutions

Alte

rnat

ives

3

4

Motivation

• Previous attempts to capture knowledge– Highly specialized tools– “Knowledge” engineer– Rationale management– Failed![1] – too much effort

• Tie visual tools to Knowledge Model– Already prevalent– No additional effort– Need grammar for each visual

Visual Tools

QFD F/M Tree

CAD SysML

C&CM …

Knowledge Model

Designer(s)

Acquisition Access &

Display

Task clarification

Decisions

[1] P. Schütt, "The post-Nonaka Knowledge Management," Journal of Universal Computer Science, vol. 9, pp. 451-462, 2003.

5

Working KnowledgeThe working knowledge consists of:• Knowledge about function, form and behavior of the product being

designed.• Knowledge about constraints, objectives and requirements that the

design should satisfy.• The alternatives that exist at each stage in the design processed

(expressed explicitly by the designer).• Representation of these entities in different levels of abstraction

Structure

Sub-structure

Behavior

Sub-Behavior Artifact

Function

Sub-Functions

Attributes

ConstraintsConstraintsConstraints

DesignModel

Objectives

Requirements

Working Knowledge

A B

Different levels of fidelity

A depends on B

Different alternatives

6

Vision

LMM=0 / CCM=1

LMM = CCM

Ucom Torso 22 1 2 2 2 2 2 2

Ucom head 1 8 2 2

Drivetrain "Pitch bottom" 2 7 1 2 1 1 2 2

Sensor "pitch bottom" 2 1 6 1 1 1 1 1

Drivetrain "Roll" 2 2 9 1 2 2 2 2

Sensor "roll" 2 1 1 7 1 1 1 2 1

inner cardan joint 1 1 2 12 1 1 2 2 2

inner cardan plate 1 1 6 2 2

outer cardan joint 1 1 1 5 2

neck base 2 1 2 2 15 2 1 2 2 1

Drivetrain "turn" 2 2 2 1 2 14 1 2 2 2 2 1

Support "turn" 1 1 6 1 2

Sensor "turn" 2 1 2 2 1 6 1

Support "pitch top" 2 7 2 1 2

Drivetrain "pitch top" 2 2 2 2 2 8 2

Sensor "pitch top" 2 1 1 1 5 2

pivot "pitch top" 1 2 2 8 2

abstract CSS "pitch bottom" 2 2 4

abstract CSS "roll" 2 2 4

abstract CSS "turn" 2 2 4

abstract CSS "pitch top" 2 2 4

abstract CSS "convey neck ba 2 2 4

abstract CSS "tool access" 1 1 2

Drive

train

"Pitc

h bo

ttom

"

Ucom

hea

d

Ucom

Tor

so

Sens

or "r

oll"

oute

r car

dan

join

t

inne

r car

dan

plat

e

inne

r car

dan

join

t

Drive

train

"Rol

l"

Sens

or "p

itch

botto

m"

Components

Com

pone

nts

abst

ract

CSS

"pitc

h bo

tto

abst

ract

CSS

"too

l acc

es

abst

ract

CSS

"con

vey

ne

abst

ract

CSS

"pitc

h to

p"

abst

ract

CSS

"tur

n"

abst

ract

CSS

"rol

l"

pivo

t "pi

tch

top"

Sens

or "p

itch

top"

Drive

train

"pitc

h to

p"

Supp

ort "

pitc

h to

p"

Sens

or "t

urn"

Supp

ort "

turn

"

Drive

train

"tur

n"

neck

bas

e

WK Model

HoQModel

…Model

Product Model

RELATIONSHIP MATRIX9 - STRONG3 - MEDIUM1 - WEAK

Engineering Characteristics (EC's)Orientation: + increase - decrease - + + + + + - - + + -

Cust

omer

Impo

rtanc

e

Max

imum

Dim

ensi

on

Nom

inal

sup

ply

volta

ge

Max

torq

ue o

f mot

or

Ove

rall

gear

ratio

n pe

r D

OF

No

of D

OF

Max

Spe

ed

Post

ion

mea

sure

men

t ac

cura

cy

Wei

ght

Max

Cur

rent

Ran

ge o

f Mot

ion

Ove

rall

effic

ienc

y

Back

lash

in D

rivet

rain

Anthropomorphism Human-like dimensions 9 9Smooth motions 6 3 9

Human-like motion Look at floor right in front 8 3 3 9Low energy requirement 3 1 3 3 9 990 degrees in one second 3 9 3Compatible with universal contro 8 9 9easy to control 5 3 9 3 9reliable and robust controls 7 3 9 9

Accurate for cameras precise positioning of head 8 3 3 9 3 9User safety no overheating when operating fo 2 3 3 9 3

Carry at least 3kg payload 5 3 9 9 1 3

Units of Target Values mm V Nm

deg/

s

kg A deg

%

Target Values 260

24 4 90 from

<2 5 90

Absolute Importance

Relative Importance

o xx

o

x

x

oo

oo

xx

xo

ox

xx

x

xx

o

o

x

Constraint solver

Optimizer

Constraint problem

Optimization problem

CAEModel

Finite Element

Solver, etc.

Decision support

tools

Visual tools

PLMAnalysis & Simulation

tools

Current Work Future Work

7

Visual ToolsØ 200 mm

Ø 100 mm

Ø 160 mm

160

mm

120

mm

140

mm

Kopf

Hals

Torso

Schulterlinie

x

y

z

2

1

3

4

RELATIONSHIP MATRIX9 - STRONG3 - MEDIUM1 - WEAK

Engineering Characteristics (EC's)Orientation: + increase - decrease - + + + + + - - + + -

Cust

omer

Impo

rtanc

e

Max

imum

Dim

ensi

on

Nom

inal

sup

ply

volta

ge

Max

torq

ue o

f mot

or

Ove

rall

gear

ratio

n pe

r D

OF

No

of D

OF

Max

Spe

ed

Post

ion

mea

sure

men

t ac

cura

cy

Wei

ght

Max

Cur

rent

Ran

ge o

f Mot

ion

Ove

rall

effic

ienc

y

Back

lash

in D

rivet

rain

Anthropomorphism Human-like dimensions 9 9Smooth motions 6 3 9

Human-like motion Look at floor right in front 8 3 3 9Low energy requirement 3 1 3 3 9 990 degrees in one second 3 9 3Compatible with universal contro 8 9 9easy to control 5 3 9 3 9reliable and robust controls 7 3 9 9

Accurate for cameras precise positioning of head 8 3 3 9 3 9User safety no overheating when operating fo 2 3 3 9 3

Carry at least 3kg payload 5 3 9 9 1 3

Units of Target Values mm V Nm

deg/

s

kg A deg

%

Target Values 260

24 4 90 from

<2 5 90

Absolute Importance

Relative Importance

o xx

o

x

x

oo

oo

xx

xo

ox

xx

x

xx

o

o

x

8

Black box diagram

}Technical process diagram

QFD 1

}Function-structureschematic

Morphological matrix

}Organ structure• Conceptual sketch• Conceptual schematic

QFD 2, Concept selection table

}Component structure• Preliminary layoutsketch

}Component structure• Dimensional layout(scale)

LegendT.P. – Technical ProcessF.S. – Function StructureCon. – Concept

P.L. – Preliminary LayoutD.L. – Dimensional LayoutNote: Visual tools implemented are indicated with italics.

SysML requirements diagram

Hierarchical Function structures

AND-OR trees

SysML parametric diagram for equations

Design sets visualization• Pareto fronts• Interval box representations• Polytope approximation

T.P.1 T.P.2 T.P.n

F.S.1 F.S.2 F.S.n

Con.1 Con.2 Con.n

P.L.1 P.L.2 P.L.n

D.L.1 D.L.2 D.L.n

Families of organs (function carriers); Combination and basic arrangement

Establish technological principles and sequence of operation

Group functions based on boundaries of technical processes

Parts, arrangement, rough form, some dimensions, material and manufacturing

Definitive arrangement, form, all dimensions; Material & manufacturing,

partial tolerances;

Design Specification

Black box

Optimal technical process

Optimal function structure

Optimal organ structure

Optimal preliminary layout

Optimal dimensional layout

Release for detailing

Established design characteristics

Typical visual tool used

(from [3] and [20])

Additional visual representations /

toolsVisual Tools

9

Approach

• What is working knowledge?– Need to understand the design

process• Develop a simple model of

working knowledge using existing design concepts

• Connect the WKM to visual tools

10

Mod

els

ConceptsRequirements Specifications Structure

Architecture Topology

Hierarchical Structure Flow Structure

Rationale Constraints

Numerical Qualitative Logical Semantic

GeometryAssembly structure Part Features

Hierarchical Behavior Objective Alternative

Architecture/Design Geometries Constraints

AbstractionsProduct Geometry Constraints Behavior

PLM

/PDM

Sys

tem

s

Hier

arch

ical

Sy

nthe

sisCo

nfig

urat

ion

and

Gene

rativ

e De

sign

Para

met

ric D

esig

n

Wor

king

Kn

owle

dge

Mod

el

Function

PortsBehavior

Desig

n Kn

owle

dge

Mod

els

Desig

n Re

posit

orie

s

Indi

vidu

al A

rtifa

cts

Only a few Many Almost all

Legend

ModelingConcepts

11

Abstractions of concepts

12

Working Knowledge Model

DesignModel

Instance

+subStructureOf

0..1

+subStructure 0..* Attribute

Constraint

Text : StringCPM2::Function

+functionOf 1

+hasFunctions

1..*

CPM2::Form

Objective

Value

DomainhasValue

Requirement

0..*

0..*

0..*

0..*

chosenFrom

hasDomain

0..*«metaclass»

AbstractableProperty

«extends»

«extends»

CPM2::Behavior

0..*

«extends»

CPM2::Geometry

CPM2::Artifact

-NameGeometry

-Icon : ImageSketch

-Icon : ImageDrawing

-Icon : Image3DModel

«metaclass»AbstractableProperty

«extends»

-NameConstraint

«extends»

Qualitative Analytical Geometric

13

Parameters

Geometry

FunctionSketch1:Geometry

Text = "Convert energy"Fn1 : Function

Name = LengthID = p_lenAttributeType = RealUnit = Inch

p_len : Parameter

Name = DiameterID = p_dAttributeType = RealUnit = Inch

p_d : Parameter

valueslowerBound = 3upperBound = 10

int_len : AtomicInterval

Name = l1EntityType = LineParameters = {p_len}

l1 : SketchEntity

Name = l2EntityType = LineParameters = {p_d}

l2 : SketchEntity

l1

l2

Name = VoltageID = p_vAttributeType = RealUnit = V

p_V : Parameter

GenericMotor : DesignModel

int_d : AtomicInterval

values = {3, 6, 12, 18}int_d : FiniteDomain

NEMA17 : Instance

NEMA17Sketch:Geometry

l11 : SketchEntity

l12 : SketchEntity

Name = LengthID = p_lenAttributeType = RealUnit = Inch

p_len : Parameter

valueObj = 7.5v_len : Value

p_d : ParametervalueObj = 2.4

v_d : Value

p_V : ParametervalueObj = 18

v_V : Value

Fn1 : Function

Example

14

Visual tools and WKM

Visu

al

tool

Concepts

Requirements (complete) (complete)

Structure

Architecture (as Means)

Topology(only

Geometric)(only

Geometric)

Hierarchical Structure (complete) (as Requirement)

(complete)

Flow StructureConstraints

Numerical (possible) (as Targets) (possible) (only equality)

Geometric (complete) Qualitative (in Roof) Logical Semantic (possible)

GeometryAssembly structure (complete) Part Features (complete)

Objective (possible) (as Objective)

Alternative

Architecture/Design(as

Competition)(as Means)

Geometries

Constraints

Working Knowledge

Model

Function

SysML Requirement

Diagram

Hierarchical Function

Structures

House of Quality 1

Morphological Matrix

2D DrawingSysML

Parametric Diagram

15

Visual Tool Grammar - examples

Design Model+realizedBy

* +performsFunction*

Function

Form

Implementation

Software

«property»

Car.minStoppingDistance

«parametricRelation»

F = ma

«parametricRelation»

Cf = Fresistive / Fnormal

«property»

Car.mass«property»Earth.gravity

ma

«property»

Car.tire.cFrictionCf

Fresistive

Fnormal

F

«parametricRelation»

F = mam

a

F

«parametricRelation»

dstop = - ½ v2 / a

dstop

va

«property»Car.speed

Design Model

EqualityConstraint

Attribute

Behavior

BehaviorModel

OperatingState

Constraint

Function-Component Matrix

SysML Parametric Diagram

15

16

Visual Tool Grammar - examplesDirection

TargetsCustomer

Requirements

Engineering Characteristics

Roof

Design Model

Attribute

Objective

Function

Requirement

Constraint

QualitativeRelationship

Matrix

QualitativeRelationships

Cus

tom

erR

equi

rem

ents

TargetsAl

tern

ativ

es

Engineering characteristics

DirectionHoQ

17

Case Study I

Humanoid Robot Neck – ARMAR III – Universität Karlsruhe, Germany

18

ARMAR III Case Study

19

HoQ of ARMAR IIIARMAR II

(Objektsystem)

Working Knowledge

of ARMAR III

Requirements for ARMAR III

Constraints & Objectives

Add

QFD

Neck:DesignModel

NeckARMARII:DesignModel

Neck3ARMARIII:DesignModel

NeckARMARII_3D:Form

PositionRobotHeadARMARIII:Requirement

AccurateForCamera:Requirement

SupplyVoltage:Parameter

Speed:Parameter

PositionAccuracy:Parameter

Weight:Parameter

Torque:Parameter

MaxCurrent:Parameter

GearRatio:Parameter

Height:Parameter

MotorEqn1:Constraint

SpeedCalc:Constraint

PrecisePositioning:Requirement

HumanLikeDimensions:Requirement

EasyToControl:Requirement

CompUnivlCntr:Requirement

ReliableRobust:Requirement

Refined by

Refined by

Refined by

Refined by

invo

lve

s

Refined by

Refined by

“Compatible with Universal Controller”

Partial instance of ARMARII neck Partial listing of ARMAR III requirements

20

Case study II

Coolant valve for IC engine Schematic

SysML Req.HoQ

Function Str. Morph. Mat.

2D Drawings

Constraint Network

21

Coolant Valve Requirements

SysML Requirements diagram

22

Coolant Valve Design

House of Quality

Function Structure

Morphological Matrix

23

Coolant Valve Design

Constraint network

Drawing Interface

(Parameters

24

Coolant Valve Design

SysML Req.HoQ

Function Str. Morph. Mat.

2D Drawings

Constraint Network

25

Application – Design for Sustainability

Competing (Existing)Products

Function / Requirements

Stapler

Top

Impact plate

IndexerMagazine

SpringGuide

Housing

Bottom

Extruder

Stapler

Extrude staple

Look good

Store staplesHold staples

Load staplesPosition staples

Attach papers

Crimp staple

Reliable

Teardown Function Analysis

Life Cycle Analysis (LCA)

Function –component relationshipFu

ncti

ons

Components

Function-ComponentMatrix

Existing design process

E-QFD

Our Approach

Voice of Customer

Engineering Characteristics

Environmental Impacts

Function-Impact Analysis (proposed)

Structure / Bill of Materials

Correlation Analysis(proposed)

RelationshipMatrix

QualitativeRelationships

Cust

omer

Requ

irem

ents

Targets

Alte

rnat

ives

Engineering characteristics

Direction

Pe

rce

nt

Imp

act

Pe

rce

nt

Imp

act

Pe

rce

nt

Imp

act

Pe

rce

nt

Imp

act

Pe

rce

nt

Imp

act

Pe

rce

nt

Imp

act

Pe

rce

nt

Imp

act

3 0 0 .2 2 3 2 0 0 .1 4 8 6 5 0 0 .3 7 1 60 .7 4 3 23 0 0 .1 3 7 25 0 0 .2 2 8 70 .4 5 7 4

5 0 .0 1 1 6 5 0 .1 4 3 51 0 0 .0 2 2 11 0 0 .0 2 2 11 0 0 .0 2 2 1 0 .2 2 0 71 0 0 0 .0 5 3 1

7 0 0 .0 1 93 0 0 .0 0 8 1 0 .0 2 7 11 0 00 .0 5 6 10 .0 5 6 1

0 .0 3 0 .0 0 8 1 0 .3 6 6 4 0 .0 2 2 1 0 .1 7 0 7 0 .1 5 9 3 0 .6 5 6 41 .5 5 7 6

Fu n ctio n - Impact M atrix

Me

tal

Stap

ler

To tal

Extr

ud

e S

tap

le

Cri

mp

Sta

ple

P in s

M agazin eImp act P lateExtru d e r

To p Ho u singB o tto m Ho using

Sto

re S

tap

les

Po

siti

on

Stap

les

Load

Sta

ple

s

Ho

ld P

aper

s

Tran

smit

Fo

rce

Envi

ron

me

nta

l Im

pact

(G

lob

al W

arm

ing)

Fu n ctio n

C o mp o n e nt

Average Impact (Global Warming)

Extrude Staple

Crimp Staple

Store Staples

Position Staples

Load Staples

Hold Papers

Transmit Force

Contribution of each function to the overall impact of the stapler.

26

Future work – Wiki Integration

Previous work (Devanathan et al, 2009)

Previous work (Li, Raskin & Ramani, 2007)

Design Semantics extraction

Linguistic Knowledge

Syntax Analysis Semantic Analysis

Lexicon

Syntax

Domain Knowledge

Domain Ontology

Semantic Rules

Wiki Pages

… The <attribute belongs_to=“Stapler”> Weight</attribute> of the <artifact> Stapler </artifact> should be kept as <objective attribute=“weight”> low</objective> as possible…

Tagging

Parsing

Structure

Sub-structure

Behavior

Sub-Behavior Artifact

Function

Sub-Functions

Attributes

ConstraintsConstraintsConstraints

DesignModel

Objectives

Requirements

Working Knowledge

Design

Information Model

Visual Tools

27

3D Hub

28

Conclusions• Working knowledge is much more than product data:

– Contains all the alternatives that were considered, and the relationships between them to easily reason among them

– Allows reasoning about the design in any level of detail and abstraction

• Important aspect of working knowledge– Allows setup of commonly used computational (simulation,

optimization, configuration etc.) and manual (QFD, Morphological matrix, etc.) decision support tools

– The decisions and the rationale (knowledge) taken using the support tools are added back into the working knowledge

– Contains the information about what design tasks have been performed and what tasks have to be done… (This is future work)

29

Publications1. S. Devanathan, C. Sauter, A. Albers, and K. Ramani. A working knowledge model for supporting early design

through visual tools, in International conference on engineering design, ICED'09, Stanford, CA, 2009.2. S. Devanathan and K. Ramani, "Creating Polytope Representation of Design Spaces for Visual Exploration

Using Consistency Technique," IDETC/CIE 2009. 31 Aug - 2 Sept. 2009, San Diego, CA, USA3. S. Devanathan, F. Zhao, and K. Ramani, “Integration of Sustainability into Early Design through Working

Knowledge Model and Visual Tools” 2009 International Manufacturing Science and Engineering Conference MSEC, West Lafayette, IN, 2009

4. D. Min, J. Cho, and K. Ramani, A method for measuring part similarity using ontology and a multi-criteria decision making method, IDETC/CIE 2009. 31 Aug - 2 Sept. 2009, San Diego, CA, USA. (Paper# DETC2009-87711)

5. Walthall, C., S. Devanathan, L. Kisselburgh, K. Ramani, and E. Hirleman. A Framework for evaluating wikis as a medium for communication within engineering design teams,. IDETC/CIE 2009. 31 Aug - 2 Sept. 2009, San Diego, CA, USA

6. C.J. Walthall, C. Sauter, T. Deigendesch, S. Devanathan, A. Albers, and K. Ramani. Survey of Wikis as a Design Support Tool. ICED'09, 24-27 Aug. 2009, Stanford, CA, USA

7. S. Murugappan and K. Ramani, "FEAsy: A Sketch-based Interface Integrating Structural Analysis in Early Design", To appear in Proceedings of the ASME 2009 International Design Engineering Technical Conferences & Computers and Information in Engineering Conference (IDETC/CIE 2009), SanDiego, CA

8. S. Murugappan and K. Ramani, "Towards beautification of Freehand Sketches using Suggestions", in review 'Sixth Eurographics Workshop on Sketch-Based Interfaces and Modeling, SIGGRAPH 2009

9. D. Cao, K. Ramani, M. W. Fu, and R. Zhang, "Port-based Ontology Semantic Similarities for Module Concept Creation,” IDETC/CIE 2009. 31 Aug - 2 Sept. 2009, San Diego, CA, USA