Smart Product Modeling: Dealing with the Issues of System Complexity

1. Smart Product Modeling:Dealing with the Issuesof System Complexity François E. Cellier, Ph.D.Professor and Director of Undergraduate StudiesDepartment of Electrical & Computer EngineeringUniversity of Arizona

2. 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. Smart Product Modeling

3. 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. Manufacturing Life Cycle

4. 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. SPM and Life Cycle Reduction

5. Taxonomy R i Iconic representation vb va u Potentials: va, vb Detailed description Voltage:u: u = va- vb Current:i: u =R ·i Organization of Knowledge Let us consider the example of an electrical resistor : 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).

6. i + U0 = f(t) i = U0 / R Different Equations - - R R Identical Objects I 0 I 0 I0 = f(t) u = R· I0  The causality of the equations must not be predetermined. It can only be decided upon after the analysis of the system topology. U 0 The Causality of the Model Equations

7. 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. Basic Requirements of OO Modeling

8. 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; 

9. 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]);equationconnect(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;

10. Models in Modelica consist of a descriptionof theirmodel structure as well as a description of their embedding in the model environment: Models in Modelica model Model name Description of the model embedding; equations Description of the model structure; end Model name;

11. 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). Model Structure in Modelica

12. Instance name Class name Modifier Connection Connector Model Topology in Modelica 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;

13. Voltage R i v v u p n connector Pin Voltage v; flow Current i; end Pin; type ElectricPotential = Real (final quantity="ElectricPotential", final unit="V"); type Voltage = ElectricPotential; Resistors in Modelica 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;

14. R i C i v u v v u v p n n p Similarity Between Different Elements 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;

15. 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; i v u v u u v v v v R i i p p n p n n C Partial Models and Inheritance

16. Courtesy Toyota Tecno-Service Decomposition and Abstraction

17. Heterogeneous Modeling Formalisms

18. Because of the sign conventions, an empty output frame ( ) must always be connected to a full input frame ( ). Mechanical Connectors connectorFrame Positionr0[3] "Distance of the frame from the inertial system"; RealS[3, 3]"Transformation matrixof the frame to the inertial system"; Velocityv[3]"Absolute velocityof the frame"; AngularVelocityw[3]"Absolute angular velocityof the frame"; Accelerationa[3]"Absolute accelerationof the frame"; AngularAccelerationz[3] "Absolute angular accelerationof the frame "; flowForcef[3] "Force acting on the frame"; flowTorquet[3] "Torque acting on the frame"; endFrame;

19. Mechanical bodies define the D’Alembert Principle for the sum of acting forces and torques. rCM Frame Center of Gravity The coordinates of the frames are first converted to 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. Mechanical Bodies I modelBodyBase"Inertia and mass properties of a rigid body"; extendsFramea; Massm; PositionrCM[3]"Distance from frame to center of gravity"; InertiaI[3, 3]; equation f = m*(a + cross(z, rCM) + cross(w, cross(w, rCM))); t = I*z + cross(w, I*w) + cross(rCM, f); endBodyBase; The D’Alembert Principle is then formulated for the center of gravity.

20. modelBody"Rigid body with one cut"; extendsFrame_a; parameterPositionrCM[3]={0,0,0} "Vector from frame_a to center of mass, resolved in frame_a; parameterMassm=0"Mass of body [kg]"; parameterInertiaI11=0"(1,1) element of inertia tensor"; parameterInertiaI22=0"(2,2) element of inertia tensor"; parameterInertiaI33=0"(3,3) element of inertia tensor"; parameterInertiaI21=0"(2,1) element of inertia tensor"; parameterInertiaI31=0"(3,1) element of inertia tensor"; parameterInertiaI32=0"(3,2) element of inertia tensor"; BodyBasebody; 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 Mechanical Bodies II

21. modelBody"Rigid body with one cut"; extendsFrame_a; parameterPositionrCM[3]={0,0,0} "Vector from frame_a to center of mass, resolved in frame_a; parameterMassm=0"Mass of body [kg]"; parameterInertiaI11=0"(1,1) element of inertia tensor"; parameterInertiaI22=0"(2,2) element of inertia tensor"; parameterInertiaI33=0"(3,3) element of inertia tensor"; parameterInertiaI21=0"(2,1) element of inertia tensor"; parameterInertiaI31=0"(3,1) element of inertia tensor"; parameterInertiaI32=0"(3,2) element of inertia tensor"; BodyBasebody; 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 Mechanical Bodies III

22. 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. Mechanical Bodies IV

23.  Geometry for the animation. Geometry for the computation of mass and inertia matrix (not represented graphically, since modeled by means of equations). Mechanical Bodies V

24. An Example I

25. An Example II

26. Cut joint Kinematic loop An Example III

27. Equations after expansion of the matrix expressions Elimination of trivial equations of the type: a = b Remaining equations after the symbolic transformation. An Example IV

28. An Example V

29. A multi-body system (MBS) consists of a combination of mechanical parts, connected to each other to support motion in three-dimensional space. Multi-body Systems Hmm! Maybe this is not yet the most luxurious model… but abstraction is everything after all.

30. 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. Properties of OO Modeling Environment

31. 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. Passive Solar Space Heating

32. Top-level Model Iconic representation Topological representation

33. Living Room Model Iconic representation Topological representation

34. The Interior Wall

35. The Window

36. The Solar Position

37. The Solar-House Package

38. Simulation Results

39. 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. Knowledge Abstraction

40. The Hemodynamic System The 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.

41. The Hemodynamic System II

42. The Hemodynamic System III

43. The Heart The 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.

44. The Thorax The 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.

45. 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. Summary

46. In theprocess 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. Summary

47. 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. Summary