Smart Product Modeling: Dealing with the Issues of System Complexity

Start of presentation

Advanced Simulation Technologies Conference

April 18-22, 2004

François E. Cellier, Ph.D.Professor and Director of Undergraduate Studies

Department of Electrical & Computer EngineeringUniversity of Arizona

Smart Product Modeling:Dealing with the Issuesof System Complexity



April 18-22, 2004

Smart Product Modeling

• Smart Product Modeling (SPM) is a term that has been coined to denote modeling support for the design and development of complex systems.

• It is often used in the context of rapid prototyping of alternate system designs.

• In SPM, models of alternate system components become interchangeable in ways that resemble physical system components.



April 18-22, 2004

Manufacturing Life Cycle• In car manufacturing, the development life cycle of

a new model is now two years. In the first year, the features of the new model are designed, whereas in the second year, the production of the new model is being designed.

• Many of the components of a car are prefabricated, and they are often outsourced. Your new “all-American” car may feature a German engine and a Japanese transmission.

• Design alternatives must be chosen, before even a real prototype of the new model has been produced.



April 18-22, 2004

SPM and Life Cycle Reduction• Complex systems can only be designed in a

short time and with limited resources, if many design decisions can be made on the basis of simulation models alone.

• Components are supposed to be delivered together with simulation models describing them.

• The object-oriented modeling of physical systems provides a means to accomplish that goal.



April 18-22, 2004

Detaileddescription

Iconicrepresentation

Taxonomy

Organization of KnowledgeLet us consider the example of an electrical resistor :

va vb

Potentials: va, vb

u

Voltage: u : u = va vb

Ri

Current: i : u = R · i

The object-oriented modeling paradigm stores the four items characterizing an object in a single place. These are: the taxonomy (naming and organization), the iconic representation (for graphical modeling), the detailed mathematical description (either in the form of equations or in the form of a topology), and the lexical information (a verbal description).



April 18-22, 2004

The Causality of the Model EquationsU 0

i+

R

I 0

I0

R

U0 = f(t)

i = U0 / R

I0 = f(t)

u = R· I0

Identical Objects

Different Equations

The causality of the equations must not be predetermined. It can only be decided upon after the analysis of the system topology.

-

-



April 18-22, 2004

Basic Requirements of OO Modeling

• Physical objects should be representable by mathematical graphical objects.

• The graphical objects should be topologically connectable.

• The mathematical models should be hierarchically describable. To this end, it must be possible to represent networks of coupled objects again as graphical objects.



April 18-22, 2004

Example of a Topological Description

model Circuit1 SineVoltage U0(V=10, freqHz=2500); Resistor R1(R=100); Resistor R2(R=20); Capacitor C(C=1E-6); Inductor L(L=0.0015); Ground Ground; equation connect(U0.p, R1.p); connect(R1.n, C.p); connect(R2.p, R1.n); connect(U0.n, C.n); connect(Ground.p, C.n); connect(L.p, R1.p); connect(L1.n, Ground.p); connect(R2.n, L.n);end Circuit1;



April 18-22, 2004

Graphical Information (Annotation)package CircuitLib annotation (Coordsys( extent=[0, 0; 504, 364], grid=[2, 2], component=[20, 20])); model Circuit1 annotation (Coordsys( extent=[-100, -100; 100, 100], grid=[2, 2], component=[20, 20])); Modelica.Electrical.Analog.Sources.SineVoltage U0(V=10, freqHz=2500) annotation (extent=[-80, -20; -40, 20], rotation=-90); Modelica.Electrical.Analog.Basic.Resistor R1(R=100) annotation (extent=[ -40, 20; 0, 60], rotation=-90); Modelica.Electrical.Analog.Basic.Capacitor C(C=1E-6) annotation (extent=[-40, -60; 0, -20], rotation=-90); Modelica.Electrical.Analog.Basic.Resistor R2(R=20) annotation (extent=[0, -20; 40, 20]); Modelica.Electrical.Analog.Basic.Inductor L(L=0.0015) annotation (extent=[40, 20; 80, 60], rotation=-90); Modelica.Electrical.Analog.Basic.Ground Ground annotation (extent=[0, -100; 40, -60]); equation connect(U0.p, R1.p) annotation (points=[-60, 20; -60, 60; -20, 60], style(color=3)); connect(R1.n, C.p) annotation (points=[-20, 20; -20, -20], style(color=3)); connect(R2.p, R1.n) annotation (points=[0, 0; -20, 0; -20, 20], style(color=3)); connect(U0.n, C.n) annotation (points=[-60, -20; -60, -60; -20, -60], style(color=3)); connect(Ground.p, C.n) annotation (points=[20, -60; -20, -60], style(color=3)); connect(L.p, R1.p) annotation (points=[60, 60; -20, 60], style(color=3)); connect(L.n, Ground.p) annotation (points=[60, 20; 60, -60; 20, -60], style(color=3)); connect(R2.n, L.n) annotation (points=[40, 0; 60, 0; 60, 20], style(color=3)); end Circuit1;end CircuitLib;



April 18-22, 2004

Models in Modelica

• Models in Modelica consist of a description of their model structure as well as a description of their embedding in the model environment:

model Model name Description of the model embedding; equations Description of the model structure;end Model name;



April 18-22, 2004

Model Structure in Modelica• The model structure in Modelica consists either of a set of

equations, a description of the model topology, or a combination of the two types of model structure descriptions.

• A topological model description is usually done by dragging and dropping model icons from graphical model libraries into the modeling window. These models are then graphically interconnected among each other.

• The stored textual version of the topological model consists of a declaration of its sub-models (model embedding), a declaration of its connections (model structure), as well as a declaration of the graphical description elements (Annotation).



April 18-22, 2004

Model Topology in Modelica

Class name

Instance name

Modifier

Connection

Connector

model MotorDrive PI controller; Motor motor; Gearbox gearbox(n=100); Shaft Jl(J=10); Tachometer wl; equation connect(controller.out, motor.inp); connect(motor.flange , gearbox.a); connect(gearbox.b , Jl.a); connect(Jl.b , wl.a); connect(wl.w , controller.inp);end MotorDrive;

motor

controller

PIn=100

Jl=10

w l

w r



April 18-22, 2004

Resistors in Modelica

Rivp vn

u

connector Pin Voltage v; flow Current i;end Pin;

model Resistor "Ideal resistor" Pin p, n; Voltage u; parameter Resistance R; equation u = p.v - n.v; p.i + n.i = 0; R*p.i = u;end Resistor;

Voltage

type ElectricPotential = Real (final quantity="ElectricPotential", final unit="V");type Voltage = ElectricPotential;



April 18-22, 2004

Similarity Between Different Elements

Rivp vn

u

model Resistor "Ideal resistor" Pin p, n; Voltage u; parameter Resistance R; equation u = p.v - n.v; p.i + n.i = 0; R*p.i = u;end Resistor;

model Capacitor "Ideal capacitor" Pin p, n; Voltage u; parameter Capacitance C; equation u = p.v - n.v; p.i + n.i = 0; C*der(u) = p.i;end Capacitor;

Civp vn

u



April 18-22, 2004

Partial Models and Inheritance

ivp vn

u

partial model OnePort Pin p, n; Voltage u; equation u = p.v - n.v; p.i + n.i = 0; end OnePort;

model Resistor "Ideal resistor" extends OnePort; parameter Resistance R; equation R*p.i = u;end Resistor;

model Capacitor "Ideal capacitor" extends OnePort; parameter Capacitance C; equation C*der(u) = p.i;end Capacitor;

ivp vn

u

R

ivp vn

u

C



April 18-22, 2004

Decomposition and Abstraction

planetary1=110/50

C4=0.12 C5=0.12

planetary2=110/50

C6=0.1

2

bearing2

C8=0.1

2

dem

ultip

lex

shaftS=2e-3

S

planetary3=120/44

C11=0.12

shaftS1=2e-3

S

C12=0.1

2

bearing1bearing4

Cou

rtes

y T

oyot

a T

ecno

-Ser

vice



April 18-22, 2004

Heterogeneous Modeling Formalisms

inertialx

y

axis1

axis2

axis3

axis4

axis5

axis6r3Drive1

1

r3Motorr3ControlqdRef

1

S

qRef

1

S

k2

i

k1

i

qddRef cut joint

q: angleqd: angular velocity

qdd: angular acceleration

qd

tn

Jmotor=J

gear=i

spring=c

fric

=R

v0

Srel

joint=0

S

Vs

-

+diff

-

+pow er

emf

La=(2

50

/(2*D

*wm

))R

a=250

Rd2=100

C=0.004*D/w m

-

+OpI

Rd1=100

Ri=10

Rp1=200

Rp2=50

Rd4=100

hall2

Rd3=100

g1

g2

g3

hall1

g4

g5

rw

cut in

iRef

qd q

rate2

b(s)

a(s)

rate3

340.8

S

rate1

b(s)

a(s)

tacho1

PT1

Kd

0.03

w Sum

-

sum

+1

+1

pSum

-

Kv

0.3

tacho2

b(s)

a(s)

q qd

iRefqRef

qdRef



April 18-22, 2004

Mechanical Connectors

connector Frame Position r0[3] "Distance of the frame from the inertial system"; Real S[3, 3] "Transformation matrix of the frame to the inertial system"; Velocity v[3] "Absolute velocity of the frame"; AngularVelocity w[3] "Absolute angular velocity of the frame"; Acceleration a[3] "Absolute acceleration of the frame"; AngularAcceleration z[3]"Absolute angular acceleration of the frame "; flow Force f[3] "Force acting on the frame"; flow Torque t[3] "Torque acting on the frame";end Frame;

Because of the sign conventions, an empty output frame ( ) must always be connected to a full input frame ( ).



April 18-22, 2004

Mechanical Bodies I• Mechanical bodies define the D’Alembert

Principle for the sum of acting forces and torques.model BodyBase "Inertia and mass properties of a rigid body"; extends Frame a; Mass m; Position rCM[3] "Distance from frame to center of gravity"; Inertia I[3, 3]; equation f = m*(a + cross(z, rCM) + cross(w, cross(w, rCM))); t = I*z + cross(w, I*w) + cross(rCM, f);end BodyBase;

FrameCenter of Gravity

rCM

The coordinates of the frames are first converted to the center of gravity.

The D’Alembert Principle is then formulated for the center of gravity.

The resulting force f and torque t are finally transformed back to the frame by means of their relative movement under introduction of the accompanying centripetal and Coriolis forces.



April 18-22, 2004

Mechanical Bodies IImodel Body "Rigid body with one cut"; extends Frame_a; parameter Position rCM[3]={0,0,0} "Vector from frame_a to center of mass, resolved in frame_a; parameter Mass m=0 "Mass of body [kg]"; parameter Inertia I11=0 "(1,1) element of inertia tensor"; parameter Inertia I22=0 "(2,2) element of inertia tensor"; parameter Inertia I33=0 "(3,3) element of inertia tensor"; parameter Inertia I21=0 "(2,1) element of inertia tensor"; parameter Inertia I31=0 "(3,1) element of inertia tensor"; parameter Inertia I32=0 "(3,2) element of inertia tensor"; BodyBase body; equation connect (frame_a, body.frame_a); body.m = m; body.rCM = rCM; body.I = [I11, I21, I31; I21, I22, I32; I31, I32, I33];end Body



April 18-22, 2004

Mechanical Bodies IIImodel Body "Rigid body with one cut"; extends Frame_a; parameter Position rCM[3]={0,0,0} "Vector from frame_a to center of mass, resolved in frame_a; parameter Mass m=0 "Mass of body [kg]"; parameter Inertia I11=0 "(1,1) element of inertia tensor"; parameter Inertia I22=0 "(2,2) element of inertia tensor"; parameter Inertia I33=0 "(3,3) element of inertia tensor"; parameter Inertia I21=0 "(2,1) element of inertia tensor"; parameter Inertia I31=0 "(3,1) element of inertia tensor"; parameter Inertia I32=0 "(3,2) element of inertia tensor"; BodyBase body; equation connect (frame_a, body.frame_a); body.m = m; body.rCM = rCM; body.I = [I11, I21, I31; I21, I22, I32; I31, I32, I33];end Body

Information extracted from type declaration



April 18-22, 2004

Mechanical Bodies IV

Coordinate transformation frame a frame b

Body calculated relative to frame a

Bodies with more than two joints have to be constructed by the modeler using additional frame translations. Such elements are not available in the MBS library as pre-designed modules.



April 18-22, 2004

Mechanical Bodies V

Geometry for the animation.

Geometry for the computation of mass and inertia matrix (not represented graphically, since modeled by means of equations).



April 18-22, 2004

An Example I



April 18-22, 2004

An Example II



April 18-22, 2004

An Example III

Cut joint

Kinematic loop



April 18-22, 2004

An Example IV

Equations after expansion of the matrix expressions

Elimination of trivial equations of the type: a = b

Remaining equations after the symbolic transformation.



April 18-22, 2004

An Example V



April 18-22, 2004

Multi-body Systems• A multi-body system (MBS) consists of a combination of

mechanical parts, connected to each other to support motion in three-dimensional space.

Hmm! Maybe this is not yet the most luxurious model… but abstraction is everything after all.



April 18-22, 2004

Properties of OO Modeling Environment• The object-oriented modeling environment supports

both flexible topological and hierarchical interconnection mechanisms.

• The environment lends itself to information hiding. The details of the models are hidden behind iconic model representations.

• The environment contains no domain-specific knowledge. The entire domain-specific knowledge is encoded in the domain libraries, such as the MBS library.



April 18-22, 2004

Passive Solar Space Heating• An experimental building

with passive solar heating is shown here from three sides.

• Solar radiation through the walls, the windows, and the ceiling is to be modeled.

• Losses are also being modeled, including the losses through the slab.



April 18-22, 2004

Top-level Model

Iconic representation Topological representation



April 18-22, 2004

Living Room Model

Iconic representation Topological representation



April 18-22, 2004

The Interior Wall



April 18-22, 2004

The Window



April 18-22, 2004

The Solar Position



April 18-22, 2004

The Solar-House Package



April 18-22, 2004

Simulation Results



April 18-22, 2004

Knowledge Abstraction• The object-oriented modeling metaphor lends

itself to knowledge abstraction.

• Thereby, it enables the modeler to formulate domain-specific knowledge in the language of the domain expert.

• Object-oriented models are thus well suited for communication of knowledge between modelers and domain experts.



April 18-22, 2004

The Hemodynamic SystemThe heart chambers and blood vessels are containers of blood. Each container is a storage of mass, thus contains a C-element.

The C-elements are partly non-linear, and in the case of the heart chambers even time-dependent.

The mSE-element on the left side represents the residual volume of the vessel.

The mSE-element on the right side represents the thoracic pressure, which is influenced by the breathing.



April 18-22, 2004

The Hemodynamic System II



April 18-22, 2004

The Hemodynamic System III



April 18-22, 2004

The HeartThe heart contains the four chambers, as well as the four major heart valves, the pulmonary and aorta valves at the exits of the ventricula, and the mitral and triscuspid valves between the atria and the corresponding ventricula.

The sinus rhythm block programs the contraction and relaxation of the heart muscle.

The heart muscle flow symbolizes the coronary blood vessels that are responsible for supplying the heart muscle with oxygen.



April 18-22, 2004

The ThoraxThe thorax contains the heart and the major blood vessels.

The table lookup function at the bottom computes the thoracic pressure as a function of the breathing.

The arterial blood is drawn in red, whereas the venous blood is drawn in blue.

Shown on the left are the central nervous control signals.



April 18-22, 2004

Summary• The Object-oriented modeling paradigm enables us

to organize and encapsulate knowledge about a system.

• The methodology allows us to manage and communicate this knowledge in natural ways, using terminology that is familiar to the domain expert.

• Each individual component model, be it a leaf model or a topological description of subsystems, can be kept small and manageable.



April 18-22, 2004

Summary• In the process of compilation, the models are

merged to form a large and monolithic set of equations.

• To obtain efficient simulation models, it may even be necessary to merge the model equations and the simulator equations (integration algorithms).

• These equations are then further processed by pruning out knowledge that is not needed for the task at hand.



April 18-22, 2004

Summary• The resulting simulation codes are as efficient

as if not more efficient than the best spaghetti code special-purpose simulators of the past.

• The technology is already widely used in the automotive industries, but is also making headway in other application domains.

• At the University of Arizona, the technology is taught in a senior/graduate level class to roughly 25 students per year.

Documents

Smart Product Modeling: Dealing with the Issues of System Complexity