compositional design and simulation of …compsim/articles/rajthesis.pdf“lotta” bhojak: you’...
TRANSCRIPT
COMPOSITIONAL DESIGN AND SIMULATION OF ENGINEERED
SYSTEMS
Rajarishi Sinha
ICES Technical Report
Institute for Complex Engineered Systems Carnegie Mellon University Pittsburgh, PA 15213, USA.
January 2002
© 2002 by Rajarishi Sinha. All rights reserved.
ii
COMPOSITIONAL DESIGN AND SIMULATION OF ENGINEERED
SYSTEMS
by
Rajarishi Sinha
A thesis submitted in partial fulfillment of the requirements for the degree of
Doctorate of Philosophy in Electromechanical Systems Design
Carnegie Mellon University
January 2002
Thesis committee:
Professor Pradeep K. Khosla
Dr. Christiaan J.J. Paredis
Professor Susan Finger
Professor Satyandra K. Gupta
Program Authorized to Offer Degree College of Engineering
iii
Extended Abstract
Compositional Design And Simulation Of Engineered Systems
by
Rajarishi Sinha
Doctor of Philosophy in Electromechanical Systems Design
Carnegie Mellon University
Professor Pradeep K. Khosla and Dr. Christiaan J.J. Paredis, Co-chairs
The realization of new electromechanical devices is characterized by ever shortening times to market, along with increasing customer demand for improved quality. The design process consumes a significant portion of the total development time, so that a company can achieve a distinct competitive advantage by shortening the design-cycle through virtual prototyping.
In this thesis, we propose to support the process of virtual prototyping of multi-disciplinary systems. We focus our attention on those aspects of modeling and simulation of the virtual prototype that are particularly important in the context of integration with design. Specifically, we further the current state-of-the-art with respect to representation, ease of use, and integration with design environments.
One of the most basic issues is that of representation. We present an attribute grammar based representation that represents the building blocks of our virtual prototype in a uniform fashion. The representation captures both the design data and the simulation models in the prototype. The prototype is represented as a set of attributes that capture its characteristics. We provide a set-theoretic formalism that describes the attributes and formal rules that govern the building blocks of our framework. We provide guidelines that indicate how the designer may extend our formalism.
Another important requirement is that simulation models be easy to create. Our virtual prototyping framework is based on the composition of port-based objects. In our framework, the designer does not have to work with equations and algorithms, and instead selects components and composes them into systems via their ports. Our
iv
algorithms automatically compose the corresponding behavioral models to create a system-level model.
In this thesis, we further the evolution towards a seamless integration of design and simulation at the system level by introducing the idea of a component object. They contain their configuration information as well as behavioral models and design data. They are connected to other component objects via ports. In our framework, the virtual prototype is created once all the component objects are interconnected.
Connecting component objects via their ports is not sufficient to create a complete system-level model. The behavioral models of each component object must also be connected to each other. However, as we will show in the thesis, merely making a connection between the modeling ports can result in an incorrect model in many cases.
For a composition operation over component objects to be successful in generating a system-level virtual prototype, component interaction models are required. We introduce the idea of component interaction models that connect the behavioral models of two interconnected component objects. Interaction models capture the physical dynamics at the interfaces between components. This thesis presents a framework that supports the representation, modeling and organization of interactions between components.
Equally important to ease of creation is the requirement that simulation models be accurate. The designer provides the design data of the component object, and sometimes it is possible to automatically extract the type and parameters of the behavioral model. We provide a framework by which consistency is maintained between the design and the mechanics simulation model of the component objects in the virtual prototype.
A component interaction model contains no design data, however the model depends on the participating component objects. We provide a framework and algorithms that extract the mechanical interaction model between two mechanically connected component objects. We use the framework to provide feedback to the designer.
We apply these ideas to a MEMS-based resonator. We model the resonator with our framework and point out the relative merits of our approach.
v
Acknowledgments
I would like to thank my advisors, Dr. Christiaan J.J. Paredis and Prof. Pradeep K.
Khosla for their guidance and support. Pradeep helped me see the big picture in my
research, so that my Ph.D. would have a good theoretical basis and at the same time be
relevant to the needs of industry. He was also patient with me, and accommodated my
slow learning curve. A very special thanks goes to Chris he is the one who has been
with me “in the trenches” throughout my Ph.D. He encouraged me when I was lost, and
enthusiastically supported me when I was on a roll. I greatly enjoyed the brainstorming
and modeling sessions that I had with him over the years.
I would also like to thank Prof. Satyandra K. Gupta and Prof. Susan Finger, the other
members of my thesis committee for guiding my research. S.K. in particular was
instrumental in the initial stages of my work, and he gave me very useful professional
advice throughout my Ph.D.
Thanks go to Prof. Benoit Morel and Prof. Mitchell Small at Carnegie Mellon, Dr. Raju
Mattikalli at The Boeing Company, and Prof. Bill Regli at Drexel University for many hours
of fruitful discussion.
Utúlie'n aurë! Aiya Eldalie ar Atanatári utúlie'n auré! "The day has come! Behold, people of the Eldar and Fathers of Men, the day has
come!" Fingon’s cry at the Nirnaeth Anrnoediad, from the Silmarillion
Well, here at last, dear friends, on the shores of the Sea comes the end of our fellowship in Middle-earth. Go in peace! I will not say: do not weep; for
not all tears are an evil. Gandalf at the Grey Havens, from the Lord of the Rings
vi
Murali Seshadri, Sitaraman Iyer and Qi Jing, helped in creating the MEMS-based
accelerometer example for the thesis. Without their advice and patient answers to my
many questions, I would have made several avoidable errors in my models. Thanks also
go to Prof. Gary Fedder and Dr. Tamal Mukherjee for giving me access to their models.
I would like to thank the other members of the Composable Simulation group: Antonio
Diaz-Calderon, Vei-Chung Liang, Li Han, Peder Andersen, Khaled Al-Ajmi and Boris
Kaminsky. The many discussions and that we had have enriched this thesis. You never
realize how much you learn in weekly group meetings until you stop attending them!
Antonio, Murali and Vei-Chung have also been good friends at Carnegie Mellon.
The research that led to this PhD thesis was funded in part by DARPA, the Raytheon
Company, DaimlerChrysler Rail Systems (Adtranz), the National Institute of Standards
and Technology, the Robotics Institute, the National Science Foundation, the
Pennsylvania Infrastructure Technology Alliance, and the Institute for Complex
Engineered Systems at Carnegie Mellon University.
My stay at Carnegie Mellon would have been dreary if it were not for Srikanth
“Cheeku” Venkatasubramanian, Vipul “Mochu” Jain, and Venkat “Avro” Ayyadevara.
Here’s to the many dinners, and movies, and late nights spent watching Beavis and
Butthead!
Antonio and Octavio Juarez: I will miss the hours we spent over lunches, discussing
everything under the sun.
vii
I owe my parents Kalyan & Akhila Sinha for bringing me up in an academically
challenging environment it is the single most important reason why I have come this far
in my education. I also owe my sister Jayanti Sinha a deep debt of gratitude for supporting
and encouraging me through these years.
To my parents-in-law Jitendra and Sulochana Bhojak: I have never met two kinder
people, and I am proud to be a part of your family. To my friend and sister-in-law Nehal
“Lotta” Bhojak: You’re still my “bestest” friend!
My friend and companion, sometime neighbor, and now my wife Tejal: I would never
have made it without you. Thank you for laughing with me when I was happy, and holding
me up when I was sad.
This too, as in all other things, I owe to you.
Rajarishi Sinha January 11, 2001
Pittsburgh, PA, USA
viii
Table of Contents
Extended Abstract .............................................................................................................. iii Acknowledgments ...............................................................................................................v Table of Contents ............................................................................................................. viii List of Figures.................................................................................................................... xii 1 Thesis Overview...........................................................................................................1
1.1 Introduction and Motivation ...................................................................................1 1.2 Thesis Objectives and Approach...........................................................................4 1.3 Related Research .................................................................................................5
1.3.1 Simulation-based Design ...............................................................................5 1.3.2 Configuration in Design and Software Engineering........................................6 1.3.3 Port-Based Modeling .....................................................................................7 1.3.4 Attribute Grammars in Design........................................................................9 1.3.5 Multibody Simulation....................................................................................10 1.3.6 Parameter Extraction from CAD...................................................................10
1.4 Thesis Contributions ...........................................................................................12 1.5 Thesis outline......................................................................................................13
2 Composition in Design and Simulation.......................................................................16 2.1 Introduction .........................................................................................................16 2.2 Composable Simulations ....................................................................................19 2.3 The Port-Based Modeling Paradigm ...................................................................22 2.4 Port-Based Modeling of Mechanical Systems.....................................................24 2.5 The Composition in Simulation and Design (COINSIDE) Environment...............25
2.5.1 Architecture..................................................................................................25 2.5.2 Data Model Modification Modules ................................................................26 2.5.3 Design Services ...........................................................................................29 2.5.4 Event-Based Synchronization ......................................................................31 2.5.5 Simulation Engine ........................................................................................32
2.6 Summary.............................................................................................................32 3 An Attribute-based Representation for Systems ........................................................34
3.1 Introduction .........................................................................................................34 3.2 Attribute Grammars in System-Level Design ......................................................37
3.2.1 Formal grammars.........................................................................................38 3.2.2 Attribute grammars ......................................................................................39 3.2.3 Grammatical representations for design ......................................................41
3.3 A Set-Theoretic Approach to Configuration Design and Simulation....................41 3.4 Ports....................................................................................................................43 3.5 Parameters .........................................................................................................45 3.6 COINSIDE Grammars.........................................................................................46
3.6.1 Port Grammars ............................................................................................46 3.6.2 Interaction Model Grammars........................................................................49
3.7 Illustrative Example .............................................................................................52
ix
3.7.1 Discussion....................................................................................................57 4 Component Objects....................................................................................................58
4.1 Introduction .........................................................................................................58 4.2 Component Objects ............................................................................................60
4.2.1 Behavioral Models .......................................................................................61 4.2.2 CAD Models.................................................................................................62
4.3 Derivation of the Behavioral Model from CAD Data ............................................64 4.4 Illustrative Example .............................................................................................66
4.4.1 Configuration................................................................................................67 4.4.2 Refinement: Configuration ...........................................................................67 4.4.3 Refinement: Modeling ..................................................................................68 4.4.4 Discussion....................................................................................................68
4.5 Summary.............................................................................................................69 5 Component Interactions .............................................................................................70
5.1 Introduction .........................................................................................................70 5.2 Behavioral models For interactions.....................................................................72 5.3 Interaction Models and Containers......................................................................73 5.4 Derivation of the Interaction Model from Component Objects.............................76 5.5 Illustrative Example .............................................................................................77
5.5.1 Initial Interaction Modeling ...........................................................................78 5.5.2 Refinement of the Interaction Model ............................................................79 5.5.3 Discussion....................................................................................................80
5.6 Limitations of Interaction Models.........................................................................81 6 Automatic Extraction of Mechanical Interaction Models .............................................84
6.1 Introduction .........................................................................................................84 6.2 Early Work on Contact Mechanics ......................................................................87 6.3 Extending Contact Mechanics to Curved Surfaces .............................................91
6.3.1 Considering Boundary Points Constant in z.................................................93 6.3.2 Considering Boundary Points Constant in θ.................................................94 6.3.3 Considering Boundary Points Varying in z and θ. ........................................94
6.4 Generalized Contact Mechanics .........................................................................95 6.5 Articulation in Assemblies .................................................................................103
6.5.1 Solving the Set of Non-Penetration Conditions for Instantaneous Articulation. ...................................................................................................................103 6.5.2 A CAD Implementation for Instantaneous Articulation ...............................105 6.5.3 Giving Feedback to the Designer...............................................................107
6.6 Illustrative Examples .........................................................................................110 6.6.1 Example 1 (Arm): Demonstration of the Framework ..................................110 6.6.2 Example 2 (1-DOF 4-Bar Linkage): Global Constraint Resolution .............113
6.7 Discussion.........................................................................................................116 6.8 Conclusions and Future Work...........................................................................117
7 Case Study: MEMS-Based Resonator .....................................................................119 7.1 Introduction .......................................................................................................119 7.2 Product Overview..............................................................................................120
7.2.1 Function and Structure...............................................................................120 7.3 Initial System Architecture and Model ...............................................................122
x
7.4 Initial Design and Modeling ...............................................................................124 7.5 Modeling Methodology: COINSIDE with Modelica ............................................126 7.6 The COINSIDE MEMS Library ..........................................................................129
7.6.1 The MEMS Connector ...............................................................................129 7.6.2 MEMS Component Objects........................................................................131 7.6.3 MEMS Component Interactions .................................................................139
7.7 Refinement of Design and Model ......................................................................143 7.8 Resonator Model...............................................................................................145 7.9 Simulation and Results .....................................................................................147 7.10 Design Verification: Finite Element Modeling....................................................148 7.11 Discussion.........................................................................................................152
7.11.1 Framework .................................................................................................152 7.11.2 Models .......................................................................................................154 7.11.3 Modeling Language ...................................................................................155
7.12 Summary...........................................................................................................156 8 Summary and Conclusions ......................................................................................157
8.1 Summary...........................................................................................................157 8.2 Review of Contributions ....................................................................................160 8.3 Discussion.........................................................................................................162 8.4 A Vision for Simulation-Based Engineered Device Design ...............................164 8.5 Future Work ......................................................................................................166
8.5.1 Modeling ....................................................................................................166 8.5.2 Integration with design tools.......................................................................168 8.5.3 Collaborative Modeling ..............................................................................168
Appendix A Formalism...............................................................................................170 A.1 General Definitions............................................................................................170 A.2 Ports..................................................................................................................171 A.3 Component Interaction Models .........................................................................174
Appendix B XML Representation for a Train-Track Port............................................176 B.1 Partial Port DTD................................................................................................176 B.2 Port XML Document..........................................................................................179
Appendix C Modelica Models ....................................................................................180 C.1 MEMS Connector..............................................................................................180 C.2 Base Classes ....................................................................................................180
C.2.1 OneMEMSConnector Model ......................................................................180 C.2.2 TwoMEMSConnectors Model ....................................................................181
C.3 Component Objects ..........................................................................................182 C.3.1 MEMSInertialSystem Model.......................................................................182 C.3.2 Generic Mass Model ..................................................................................182 C.3.3 Generic Spring Model ................................................................................183 C.3.4 Generic Damper Model..............................................................................184 C.3.5 Resistor Model (from Modelica Electrical Library)......................................185 C.3.6 Electrical Ground Model (from Modelica Electrical Library)........................185 C.3.7 Anchor Model.............................................................................................185 C.3.8 Cut Anchor Model ......................................................................................186 C.3.9 Beam Stiffness Model ................................................................................188
xi
C.3.10 Beam Model...............................................................................................190 C.3.11 Comb Mass Model .....................................................................................191 C.3.12 Comb Drive Model .....................................................................................193 C.3.13 Rigid Plate Model.......................................................................................194 C.3.14 Uspring-Right Model ..................................................................................198 C.3.15 Uspring-Left Model.....................................................................................199 C.3.16 Resonator Model........................................................................................200 C.3.17 Resonator Test Case Model ......................................................................202
C.4 Component Interactions ....................................................................................203 C.4.1 MEMS Transformation Model ....................................................................203 C.4.2 Electrostatic Gap Model.............................................................................204
C.5 External Sources...............................................................................................206 C.5.1 DC Voltage Source Model (from Modelica Electrical Library) ....................206 C.5.2 AC Voltage Source Model (from Modelica Electrical Library).....................206 C.5.3 Voltage-Controlled Voltage Source Model (from Modelica Electrical Library) .. ...................................................................................................................206 C.5.4 External Force Model.................................................................................206 C.5.5 Sinusoidal Signal Model (from Modelica Block Library) .............................207
Bibliography.....................................................................................................................208
xii
List of Figures
Figure 1.1. Relationship between form, function and behavior of design representations...5 Figure 1.2. Thesis overview...............................................................................................14 Figure 2.1. A joint constraint captures the contact interaction between two rigid bodies A
and B. CA and CB are the positions of the centers of gravity and P1 and P2 are the contact points. ............................................................................................................23
Figure 2.2. The schematic shown in Figure 2.1 can be mapped into a port-based block diagram that captures the system. Interaction of each block with other blocks is via ports, where energy flow takes place. Each block encapsulates a behavior model for that entity. A ...............................................................................................................24
Figure 2.3. Java-Based GUI components and services interact with the design data model. ........................................................................................................................25
Figure 2.4. Configuration editor GUI..................................................................................26 Figure 2.5. 3D viewer GUI. ................................................................................................27 Figure 2.6. Component repository GUI (left) and structure GUI (right). .............................28 Figure 2.7. Parameter editor GUI. .....................................................................................29 Figure 2.8. Modelica behavioral modeling GUI..................................................................31 Figure 2.9. Modelica time-series output. ...........................................................................32 Figure 3.1. System-level components are of two types - component objects and
component interactions ..............................................................................................35 Figure 3.2. Attribute Grammars in System-Level Design ..................................................37 Figure 3.3. An attribute grammar to generate Cartesian motion [24]. The subscripts 1 and
2 are used to differentiate between the two path attributes.......................................39 Figure 3.4. XML representation of the attribute grammar in Figure 3.3. The production
rules are not represented in the DTD. ........................................................................40 Figure 3.5. Ports on a component object...........................................................................43 Figure 3.6. Attribute representation of a port. ....................................................................46 Figure 3.7. Important axioms in the port formalism. ..........................................................47 Figure 3.8. Partial port grammar........................................................................................48 Figure 3.9. Attributes for the partial port grammar in Figure 3.8. .......................................48 Figure 3.10. Attribute grammar GUI ..................................................................................49 Figure 3.11. Required attributes for interaction models.....................................................51 Figure 3.12. Abstraction of a train-track interaction. Each block represents a component in
the configuration layer, and a circle represents a port on the component interface. ..52 Figure 3.13. Train-track Port..............................................................................................53 Figure 3.14. Port maps for the train-track interaction model..............................................54 Figure 3.15. Wheel and Brush Port. ..................................................................................55 Figure 3.16. Wheel-track interaction model for the train....................................................56 Figure 4.1. Design as a process of configuration of components and selection of
behavioral models for the components and connections............................................59 Figure 4.2. Components may encapsulate configurations of sub-components. ................60
xiii
Figure 4.3. A behavioral model container containing behavioral models. Behavioral models describe the physical or informational behavior of a component. ..................62
Figure 4.4. CAD model container. .....................................................................................63 Figure 4.5. The relation between form and behavior parameters. .....................................65 Figure 4.6. High-level component configuration for a single car train interacting with a
track. Each block represents a component, and a circle represents a port on the component interface. Lines represent non-causal connections and arrows represent directed connections. .................................................................................................68
Figure 5.1. Composition of behavioral models in the electrical and mechanical domains. In (a) the composition occurs via the application of Kirchoff’s Laws. However, in (b), applying Kirchoff’s Laws results in an incorrect rigid joint...........................................74
Figure 5.2. Interaction model as a container for a set of reconfigurable models. In this example, the container lists two possible behavioral models for this interaction. .......75
Figure 5.3. Interactions between system components. .....................................................76 Figure 5.4. Train-track interaction model container that captures all the candidate
interaction models that can model the connection between the train and the track. ..78 Figure 5.5. The train-track interaction model at the early design stage. The mechanical
interaction has been disaggregated into the individual ports for the four wheels of the train. ...........................................................................................................................79
Figure 5.6. The train-track interaction model in the detailed design stage. The mechanical interaction has been refined to a rolling joint with rolling friction.................................80
Figure 5.7. In (a), the mechanical interaction between the shaft and the bearing is localized their interfaces the outer curved surface of the shaft and the inner curved surface of the bearing. However, in (b), The gravity interaction between the planet and the satellite is not limited to the surface, and involves the entire mass of both components (image from NASA MAP Science Team). ..............................................82
Figure 6.1. Non-penetration condition at a point. Planes 1 and 2 are coplanar but are shown as separated for clarity....................................................................................89
Figure 6.2. Non-penetration condition along a line. rr is the position vector of an arbitrary
point along the contact line between P1 and Q1. Planes 1 and 2 are coplanar but are shown as separated for clarity....................................................................................90
Figure 6.3. Non-penetration condition in a polygonal surface. rr is the position vector of an
arbitrary point within the polygon bounded by P1, Q1 and R1. Planes 1 and 2 are coplanar but are shown as separated for clarity. ........................................................90
Figure 6.4. Plane containing rr also contains the normal vectors to r
r..............................99 Figure 6.5. Contact graph for a 4-part assembly. Nodes represent the four parts. Edges
represent the contacts. The contact surface that forms the intersection set is shown in each edge ................................................................................................................105
Figure 6.6. 4-part assembly with 3 degrees of freedom. .................................................109 Figure 6.7. Formation of the Matrix Representation. .......................................................112 Figure 6.8. Mapping feasible solutions to assembly joints...............................................113 Figure 6.9. 4-Bar Linkage................................................................................................114 Figure 7.1. Resonator mechanical structure....................................................................120 Figure 7.2. Fundamental model for the mechanical response of an accelerometer [121].
.................................................................................................................................121 Figure 7.3. Basic MEMS component objects and component interactions......................130
xiv
Figure 7.4. Compound components. ...............................................................................132 Figure 7.5. Material properties of poly-silicon. .................................................................134 Figure 7.6. Simple cantilever beam configuration, Modelica output and layout verification.
.................................................................................................................................136 Figure 7.7. Spring suspensions .......................................................................................138 Figure 7.8. Electrostatic port............................................................................................140 Figure 7.9. Electrostatic interaction model attribute representation.................................141 Figure 7.10. Resonator icon in Modelica. The icon represents the physical layout. ........145 Figure 7.11. Resonator configuration in Modelica. ..........................................................146 Figure 7.12. Resonator test case – embedded in a vehicle.............................................147 Figure 7.13. Resonator test case configuration. ..............................................................148 Figure 7.14. Resonator FEM model setup in ANSYS DesignSpace................................149 Figure 7.15. Resonating frequencies for the resonator. ..................................................150 Figure 7.16. Damping interaction in the U-spring. ...........................................................153
1
1 Thesis Overview1
1.1 Introduction and Motivation
Manufacturing companies design and fabricate new products for their respective
markets. In an increasingly competitive business environment, the time-to-market is
continually decreasing, and customers increasingly demand better quality. It is important
for companies to be able to design and test the behavior of their products under these
market conditions. Often, physical prototyping is used for this purpose.
Physical prototyping, even for relatively simple products, can be an expensive and
time-consuming process. Design iterations are lengthened by the manufacturing time and
physical analysis time for the prototype. Sometimes, special tools, fixtures and dies are
required that are no longer useful once the prototyping stage is complete.
1 This chapter is partly based on the following published paper:
• Paredis, C.J.J; Diaz-Calderon, A.; Sinha, R.; and Khosla, P.K., "Composable Models for Simulation-Based Design", Engineering with Computers, 17(2):112-128, 2001.
Knowledge, the object of knowledge and the knower are the three factors which motivate action; the senses, the work and the doer comprise the
threefold basis of action. The Bhagavad Gita
As a man can drink water from any side of a full tank, so the skilled theologian can wrest from any scripture that which will serve his purpose.
The Bhagavad Gita
The engineer's first problem in any design situation is to discover what the problem really is. Unknown
2
Many companies are resorting to simulation tools to improve their design process an
activity known as virtual prototyping. A well-publicized example of virtual prototyping is the
design of the Boeing 777 airplane [153]. Boeing switched from a paper-based design
process to a fully digital representation, allowing them to perform performance analysis
(using CFD software) and assemblability analysis without the need for building physical
prototypes. This resulted in a significantly shorter design and testing period. A similar all-
digital approach is being adopted by car manufacturers.
Modeling and simulation enables designers to test whether design specifications are
met by using virtual rather than physical experiments. The use of virtual prototypes
significantly shortens the design cycle and reduces the cost of design. It further provides
the designer with immediate feedback on design decisions which, in turn, promises a
more comprehensive exploration of design alternatives and a better performing final
design. Simulation is particularly important for the design of multi-disciplinary systems in
which components in different disciplines (mechanical, electrical, embedded control, etc.)
are tightly coupled to achieve optimal system performance. The exploration of large
design spaces to discover optimal designs is also aided by simulation.
The goal of this thesis is to present and develop a new framework for virtual
prototyping. Our framework is based on composition and closely integrates the product
design process with behavioral simulation.
We limit the scope of this thesis by concentrating on system-level modeling. At a
systems level, components and sub-systems are considered as black boxes that interact
with each other through a discrete interface. In general, such systems can be modeled
using differential algebraic equations (DAEs) [11] and/or discrete event systems
3
specifications (DEVS) [165]. We will not consider the systems that require partial
differential equations or finite element models to model system components or component
interactions.
We further focus our attention on these aspects of modeling and simulation that are
particularly important in the context of design. Other researchers have considered
aspects related to conceptual design [31]. In this thesis, we evaluate the current state-of-
the-art with respect to ease of model creation, model reuse and integration with design
environments.
Simulation models should be easy to create and reuse. Creating high-fidelity
simulation models is a complex activity that can be quite time-consuming. Object-oriented
languages provide clear advantages with respect to model development, maintenance,
and reuse. We introduce new constructs that form the building blocks of our framework.
When the designer uses these building blocks, he can simultaneously design and simulate
electromechanical systems.
In addition, to take full advantage of simulation in the context of design, it is necessary
to develop a modeling framework that is integrated with the design environment, and that
provides a simple and intuitive interface that requires a minimum of analysis expertise. A
complete representation of the virtual prototype will incorporate a design aspect and a
model aspect. It is important to ensure that these two aspects are consistent with each
other. Our building blocks couple these two aspects of the representation. We introduce
algorithms that maintain the consistency between the aspects.
4
1.2 Thesis Objectives and Approach
The objective of this thesis is:
Develop a virtual prototyping framework that is integrated with design by which the
designer can easily create accurate models of multidisciplinary systems.
We achieve this goal by the following approach
• Define building blocks for the framework that permit a compositional approach
to virtual prototyping.
• Define a representation that captures our building blocks in a uniform fashion,
and easily grows in detail as the design process progresses.
• Develop algorithms that can automatically extract portions of the representation
from design data.
We restrict our focus in the following ways:
1. We consider devices to be composed of interconnected elements.
2. The elements achieve the function of the device by the exchange of energy
and signals.
3. This thesis focuses on mechanical, electrical and signal exchange between the
interconnected elements. In particular, our algorithms are written specifically to
obtain mechanical models from design data.
5
4. The exchange of energy is restricted to the interface to the elements. Physical
interconnections that have a distributed, field characteristic are not considered
in this thesis.
1.3 Related Research
In this section, we present the relevant areas of research that significantly impact this
thesis. In addition, each subsequent chapter also contains references to other work that is
relevant to that chapter.
1.3.1 Simulation-based Design
The success of simulation-based design has already been demonstrated commercially.
However, many unresolved research issues remain to be addressed. Ongoing research
includes model validation [18], automatic meshing and model creation [161], integration of
simulation engines in different domains [150], architectures for collaboration [72], and
visualization using virtual reality technology [34]. In this thesis, we focus on simplifying the
process of model creation, by integrating form and behavior into component objects.
FormSynthesis Modeling
BehaviorFunction
Analysis
FormSynthesis Modeling
BehaviorFunction
Analysis
Figure 1.1. Relationship between form, function and behavior of design representations.
6
Our approach is based on the characterization of a design prototype by its form,
function, and behavior [105]. The form is a description of the physical embodiment of an
artifact, while function is the purpose of the artifact— the behavior that the designer
intended to achieve. As is illustrated in Figure 1.1, the actual behavior does not depend
on the function, but only on the form. During design or synthesis, we transform function
into form, while, during design verification, we derive the behavior from the form and verify
whether this behavior matches the function. In the context of virtual prototyping, the
behavior is described by mathematical models and design verification is achieved by
performing simulation experiments with these models.
1.3.2 Configuration in Design and Software Engineering
Our framework is driven by configuration of components that contain analysis models,
with rules imposed by a set-theoretic formalism. At the present time, our framework does
not incorporate optimization capabilities; we restrict ourselves to analysis of a single
configuration at a time. Configuration has been studied in the context of design
specification. Feldkamp et al. [53] use port-based composition to describe hierarchical
configurations of complex engineering design specifications. Motta and Zdrahal [91] look
at solving parametric design problems using configuration. Gandhi and Robertson [58]
describe a conceptual data model for the configuration of design specifications. We
extend these ideas in Chapter 4 by incorporating analysis models in the configuration
model.
Other researchers have looked at the configuration problem from a mathematical and
set-theoretic perspective. Some of these results that relate to engineering design and
simulation include Wache and Kamp [156] who have recognized that relationships in
7
configuration problems can include “physical laws in a technical domain”, part-whole
taxonomies, and “procedures in the mechanical engineering domain”. Burckert et al. [26]
describe the role of formal domain knowledge in configuration problems. Sattler [121]
defines a description logic for part-whole relations. In Chapter 3, we define a set-theoretic
formalism that imposes rules on ports, and interaction models.
Configuration also plays an important role in component-based software engineering.
Components are used to describe specific software services, and ports are used to
connect components together [5, 50, 84]. Other researchers have used type systems to
enforce rules governing software component composition [79]. In Chapter 3, we define
type systems that govern ports used in engineering design and simulation.
1.3.3 Port-Based Modeling
The software design methodology of object-oriented programming can be applied to
systems modeling as well, with the benefits of simplified model creation and maintenance.
In this thesis, we object-oriented principles in defining the building blocks for virtual
prototypes.
An important principle of object-oriented programming is that of information hiding or
encapsulation: an object can only be accessed through its public interface, which is
independent of the underlying implementation. The same principle can be applied to
modeling by making a clear distinction between the physical interactions of an object with
its environment (interface) and its internal behavior (implementation) [30, 42, 164]. The
advantage of encapsulation is that a system can be modeled by composing and
8
connecting the interfaces of its sub-systems, independently of the future implementations
of these subsystems [42, 164].
To achieve encapsulation, we use a port-based modeling paradigm that is based on
two concepts: ports and connections [41]. We describe the paradigm in Chapter 2.
Ports correspond to the points where a component exchanges energy with the
environment - one port for each separate interaction point. The interactions between
components are represented by connections between ports. Each connection imposes
algebraic constraints on the port variables. These constraints are the equivalents of the
Kirchhoff voltage and current laws in electrical circuits. One type of constraint requires
that the across variables be equal, the other that the sum of the through variables be zero.
As a reflection of the underlying physics, both connections and ports are undirected.
In mathematical terms, this requires that the components and connections be modeled as
declarative equations rather than assignments. Many recent simulation languages are
declarative, including Modelica [49], VHDL-AMS [70], and Dymola [44]; SimuLink [147], on
the other hand, is procedural.
All the ports combined form the interface of the model. This interface defines how the
component can interact with the other components in the system, but does not contain any
information about the internal behavior of the component. Instead, the interface
encapsulates the implementation of the model, which defines the internal behavior of the
component
The port-based modeling paradigm cannot be applied to all systems; it is limited to
systems with lumped interactions. When an interaction is distributed in nature, as
between a boat and the water on which it floats, it must be approximated by a large
9
number of lumped interactions. The internal model of a component, however, may still be
distributed. Consider, for example, a flexible beam attached to a structure by its two ends.
A finite element model may describe the internal behavior of the beam, but the interaction
with the structure can still be captured with only two ports. For mechatronic systems, the
primary interactions between components tend to be lumped, so that the port-based
modeling paradigm is applicable. Only when very detailed models are required, may we
have to consider phenomena, such as thermal interactions, that are distributed in nature.
1.3.4 Attribute Grammars in Design
Formal grammars have been the subject of extensive research in the fields of logic
programming [32] and design automation [55, 97, 115]. They have been used to formalize
conceptual design [9], architectural design [120], shape generation [2, 3, 28, 29] and
configuration of heat exchangers [65]. Grammars have been used to model configuration
spaces of relative motions between parts [142].
Attribute grammars are extensions to formal grammars that associate attributes and
rules to the tokens in the formal grammar. Due to the limitations of using formal grammars
to represent semantics, attribute grammars were developed for use in the development of
formal languages and software compilers [36-38, 107, 157]. These ideas have been
adopted for use in the hardware design field [45, 46, 47, 48, 68, 143, 144], in VLSI design
automation [20] as well as for mechanical design automation [152]. We build on these
concepts and provide an attribute-based formalism for use in both the configuration and
analysis phases of the iterative design process.
10
Several researchers have investigated the applicability of formal grammars in
mechanical design [9, 28, 55, 97]. However, there has not been a significant effort to
formalize the representation of system-level design and simulation. In this thesis, we
present attribute grammars for system-level design.
1.3.5 Multibody Simulation
Baraff [21] used algorithmic methods to simulate the mechanical dynamics of multi-
body systems with constraints. Such an approach involves setting up the ordinary
differential equations (ODEs) that govern the dynamics of the multi-body system, and
solving them using variable step numerical methods. Our framework extends this
approach by allowing for the composition of models, or hierarchical systems, and for the
easy definition of joint constraints. Orlandea et al. [102, 103] showed that springs and
dampers could be modeled using sparse systems of linear equations. This work was
subsequently incorporated in the ADAMS system [90]. However, unlike ADAMS, our
framework can automatically derive the behavioral models of the components from the
geometry.
1.3.6 Parameter Extraction from CAD
An important feature of this research is the introduction of mathematical models that
capture the physical dynamics at the interfaces of components in the design and the
automatic extraction of these models from geometry. For a better virtual prototype, our
framework can extract a mechanical behavioral description from the design geometry. The
algorithms that analyze geometry to obtain insight into its physical behavior are broadly
classified as geometric and assembly modeling.
11
Work in the area of representing and deriving the articulation behavior of assemblies
can be broadly classified into three groups: rule-based methods, algebraic methods, and
group-theoretic methods.
The earliest works on assembly modeling [6] presented the definitions for part mating
constraints. Tilove [149] described a method to define links and joints to support animation
of assemblies. Thomas and Torras [148] reported a method to determine the final relative
positions of parts in an assembly given the geometry of the parts and the mating
constraints. Turner et al. [151] present a method to obtain the degrees of freedom of a part
in an assembly from its mating constraints. Mattikalli and Khosla [86] describe a method to
obtain degrees of freedom from component mating constraints, wherein they use a unit
sphere to represent the space of all available degrees of freedom. Wilson and Latombe
[162] introduce the concept of a non-directional blocking graph which describes the
allowed degrees of freedom after surface mating constraints have been considered.
Anantha et al. [7] describe assembly modelling by the satisfaction of geometric
constraints.
Ge and McCarthy [59] characterize the space of possible relative positions of two
components using the Clifford Algebra. Liu and Popplestone [82] present a method to
describe surface contacts in terms of symmetry groups. However, group-theoretic
methods do not lend themselves to easy automation.
Other researchers have presented work on assembly modelling systems [75, 77, 113,
149] which handle mating conditions and kinematic simulation. Rocheleau [117] described
an assembly representation which used connectivity sets to store assembly data
hierarchically and including pair-wise topological relationships.
12
Our research, presented in Chapter 6, is based on algebraic methods and extends
work done on polygonal geometries. Techniques have been developed to predict the
instantaneous degrees of freedom from the CAD models of parts composed of polygonal
planar faces [88]. These techniques handle only parts with planar faces; most mechatronic
devices have curved parts. When curved parts are approximated as piecewise planar
parts, erroneous results are likely. In this thesis, we reason about the degrees of freedom
at each joint, based on surface mating constraints that are in turn obtained from analyzing
the nature of body-to-body contact. We obtain a set of properties that must be satisfied by
a general contact surface in order to obtain linear models. We describe a method by which
the space of allowable motions in the device can be described concisely.
1.4 Thesis Contributions
The contributions of this thesis to the state-of-the-art are:
A new framework for virtual prototyping. We define a framework that supports the
simultaneous design and behavioral simulation of multidisciplinary systems. Our building
blocks for virtual prototypes contain both design data and simulation models. Our
framework supports and maintains consistency within and between building blocks
(Chapter 2).
Building blocks for virtual prototypes. We define the building blocks for rapid
virtual prototyping. We use the composable simulation paradigm to compose system-level
models using our building blocks (Chapters 2 and 4).
13
Representation of virtual prototypes. We define a formal grammar to represent our
building blocks in the virtual prototype (Chapter 3).
Component Interaction models. When two building blocks are connected together,
there are physical phenomena that occur at the interfaces between the blocks that must
also be modeled. We capture these phenomena in interaction models (Chapter 5).
Algorithms to automatically extract mechanical interaction models from design
data. The type and nature of the interaction models depends on the two connected
blocks. We present algorithms and a framework that will extract the model from the design
data of the building blocks.
1.5 Thesis outline
The goal of this thesis is to make virtual prototyping an easier and more accurate task
for designers (Figure 1.2). We pursue a two-track approach to realizing these goals: we
create virtual prototypes by the composition of building blocks, and we interleave the
process of design and simulation. We provide a framework that incorporates a formal
representational aspect, and an algorithmic aspect.
An introduction to the area of port-based modeling is provided in Chapter 2. We then
describe how it relates to mechanical systems modeling.
14
The formal aspect is described in Chapter 3. We present a formal theory and a
grammar that captures the representation of entities in the design. Specifically, we
demonstrate how the grammar can be used to represent ports and physical interactions
between device components. We also define a relationship between the composition of
components and the composition of behavioral models. We use this relationship in later
chapters to demonstrate the utility of models for physical interactions between
components. The building blocks of simulation-based design, namely component objects
and component interactions are defined and described in Chapters 4 and 5, respectively.
The algorithmic aspect is introduced in Chapter 2 as a many-many relationship
between form and mechanical behavior. In Chapter 4, we introduce algorithms that extract
the behavioral models for component objects from their design data. In Chapter 6, we
Figure 1.2. Thesis overview.
15
introduce a framework and algorithms that extract the mechanical interaction between
component objects. We present a geometric Proposition and a set of Corollaries that lay
the mathematical foundation of the algorithms.
In Chapter 7, we present an example electromechanical system a MEMS resonator.
We use the example to demonstrate the ideas developed in the thesis.
16
2 Composition in Design and Simulation2
2.1 Introduction
A design process is a set of activities, steps, procedures, methods, or behaviors
employed to carry out the purpose of design. It involves agents that carry out the process,
the artifact being designed, and the domain knowledge [160]. The space of possible
designs is vast possibly infinite. Rigorous theories and methods are needed to arrive at a
satisfactory design given some resource constraints. Researchers have created several
design methodologies, including systematic design, case-based design, and multi-domain
energetic design [159].
2 This chapter is based on the following published papers:
• Sinha, R.; Paredis, C.J.J.; Liang, V.; and Khosla, P.K., “Modeling and Simulation to Support Virtual Prototyping of Mechatronic Systems”, ASME Journal of Computing & Information Science in Engineering, 1(1):84-91, March 2001.
• Paredis, C.J.J; Diaz-Calderon, A.; Sinha, R.; and Khosla, P.K., “Composable Models for Simulation-Based Design”, Engineering with Computers, 17(2):112-128, 2001.
• Sinha, R.; Paredis, C.J.J.; and Khosla, P.K., "Kinematics Support for Design and Simulation of Mechatronic Systems”, Proceedings of the 4th IFIP Workshop on Knowledge-Intensive CAD, May 22-24, 2000, Parma, Italy.
Nothing is particularly hard if you divide it into small jobs. Henry Ford
The man who removes a mountain begins by carrying away small stones. Chinese Proverb
Theories should be as simple as possible, but not simpler. Albert Einstein
17
Systematic design was first formalized by Pahl and Beitz [105]. They created a
methodology for identifying the required functions of an engineering system and then
reducing the requirements to smaller and smaller elements of a complete design. They
have developed a software system that supports each of the individual steps in this
process, but it is up to the designer to make the intellectual connections between each of
the steps. The method seems most applicable to discrete systems made of identifiable
elements such as "motor" or "gearbox". Design of these individual elements is usually
impossible by a similar reduction unless compromises are admitted in weight, size, or
energy consumption.
Case-based theories create new designs by selecting elements from a database of
old designs, and then modifying them for the current design requirements. Modification
proceeds by the application of rules that map differences in functional specification to
differences in structure. Sycara and Navinchandra [140] apply this paradigm to the design
of fluid-mechanical devices such as faucets. Rivard and Fenves [116] apply case-based
reasoning to the conceptual design of buildings. Watson and Perera [158] present a
review of case-based design and its application to building design. Hua et al. [69] describe
a case-based geometric design system. Maher and de Silva [85] describe a case-based
design system for structural synthesis. In all of these methodologies, however, the number
of rules grows very rapidly for even moderately complex designs, making the design of
real-world systems difficult.
Paynter [109] was one of the early proponents of modern energetic design
methodology. He showed that systems composed of discrete mechanical, electrical,
electro-magnetic, acoustic, and thermal elements can be modeled by a unified set of
18
dynamic equations that capture power or energy transactions between the elements. He
unified these with the bond graph notational modeling system. This method works well for
discrete systems made of connected elements but is awkward for distributed systems
such as vibrating elements with thousands of natural modes. More important, the models
capture power relationships but not the geometry.
From this discussion is it evident that there exists a need for a design methodology
that is applicable to general multidisciplinary systems, accounts for energy transfer
between elements, and is closely integrated with analysis models. In addition, the quality
of the models must be such that they can replace physical prototyping in several stages of
the design. Such virtual prototyping will shorten the design cycle [63]. A virtual prototype
enables the designers to test initially whether the design specifications are met by
performing simulations rather than physical experiments. Not only does virtual prototyping
make design verification faster and less expensive, it provides the designer with
immediate feedback on design decisions. This in turn promises a more comprehensive
exploration of design alternatives and a better performing final design. To fully exploit the
advantages of virtual prototyping, however, simulation models have to be accurate and
easy to create.
Virtual prototypes need to model the behavior of the equivalent physical prototype
adequately accurately; otherwise, the predicted behavior does not match the actual
behavior resulting in poor design decisions. But creating accurate models is a hard
problem. Only recently has computing performance reached a level where high fidelity
simulation models are economically viable. For instance, it is now feasible to evaluate
dynamic simulations of finite element models for crack propagation [100, 139]. However,
19
not always are the most detailed and accurate simulation models also the most
appropriate; sometimes it is more important to evaluate many different alternatives quickly
with only coarse, high-level models. For instance, at the early stages of the design
process, detailed models are often unnecessary because many of the design details still
have to be decided and accurate parameter values are still unknown. At this stage, the
accuracy of the simulation result depends more on the accuracy of the parameter values
than on the model equations; simple equations that describe the high-level behavior of the
system are then most appropriate.
Equally important to accuracy is the requirement that simulation models be easy to
create. Creating high-fidelity simulation models is a complex activity that can be quite
time-consuming. To take full advantage of virtual prototyping, it is necessary to develop a
modeling paradigm that supports model reuse, that is integrated with the design
environment, and that provides a simple and intuitive interface which requires a minimum
of analysis expertise. This chapter introduces such a paradigm, composable simulation
and design, which is based on model composition from system components.
2.2 Composable Simulations
To provide better support for simulation-based design of mechatronic systems, we
have developed a modeling and design paradigm based on composition [106]. A wide
variety of products, ranging from consumer electronics to cars, contain mostly off-the-
shelve components and components reused from previous design generations; for
instance, in cars, the portion of completely new components is often less than twenty
percent. Some other products have a modular product architecture allowing them to be
20
customized for a particular application or mass-produced at low cost [19]. As a result, the
design of such systems consists primarily of the configuration or assembly of existing
components.
The modeling of such systems can also be viewed as composition. We can obtain a
system level simulation model, by combining the component models with the models that
define the interactions between the components. Assuming that the models for individual
components already exist in a component library, and that the physics of the interactions
between the components have been modeled in a library of interaction models, a system
level simulation model can be generated through the composition of existing component
and interaction models.
To take advantage of the parallelism between the design and modeling activities—
both consist of the composition of system components— we have developed a modeling
and design framework in which the form and the behavior of a component are combined
into a single component object. By composing component objects into systems, a
designer simultaneously designs and models new artifacts. This is already common
practice in electrical CAD software; when creating a chip layout, the instantiation of a
transistor or logic gate creates the geometry for the silicon layers as well as the
corresponding simulation model.
In mechanical CAD, the integration between design and simulation is not as common.
For purely mechanical systems, most commercial CAD packages do provide an optional
module for multi-body simulation, but these modules lack sufficient support for multi-
disciplinary systems.
21
Our goal is to extend this design paradigm to multidisciplinary systems, specifically
mechatronic systems [130]. The traditional design approach for multidisciplinary systems
has been a sequential design-by-discipline approach: First design the mechanical system,
than the sensors and actuators, and finally the control system [126]. This approach
imposes artificial constraints by fixing the design at various points in the design sequence.
In mechatronic design, on the other hand, synergy between the different disciplines is
achieved by designing all disciplines concurrently. To evaluate whether a mechatronic
design prototype meets the design specifications, the designer must consider the
component interactions in all energy domains. This would be prohibitively expensive
without the intensive use of simulation.
Existing simulation tools for multidisciplinary systems are very general, stand-alone
tools that are not integrated with the design environment. The main goal of the simulation
and design framework that we have developed is to support multidisciplinary simulation-
based design within an integrated software environment. Specifically, the framework has
the following characteristics:
A port-based modeling paradigm: To take advantage of the compositional nature
of both design and modeling of mechatronic systems, we use a port-based modeling
paradigm in which the user can compose system-level simulations from component
models [41]. By connecting the ports of the subcomponents, the user defines the
interactions between them. In subsequent sections, we will describe the port-based
modeling paradigm in more detail.
22
Simulation integrated with CAD: The building blocks in our simulation and design
environment are component objects; they describe both the form and the behavior of
system components. In subsequent chapters, we describe how the CAD description of
the form may be used to extract the lumped parameters of the behavioral models. In
addition, we have developed algorithms that instantiate models of mechanical interactions
based on the form of the interacting components.
2.3 The Port-Based Modeling Paradigm
We view systems as structures of inter-connected elements interacting with the
environment. Elements in the system interact with each other through ports [41]. Ports are
points on the boundary of the system where energy is exchanged between the system
and the environment. Each interaction point has a port, and each port belongs to a
particular energy domain.
Energy flow through a port is described by an across variable and a through variable.
An across variable represents a value measured between a global reference and the port,
such as a velocity, while a through variable represents a value measured through the
element, such as a force. An across and through variable pair is usually chosen such that
their product has units of power ([M]1[L]2[T]-3). However, across variables may be replaced
by their derivatives or integrals. For instance, position can be used instead of velocity.
A connection between ports results in algebraic constraints between the port
variables. The constraints are described by the Kirchhoffian network laws:
23
A Bacross variable across variable= (2.1)
and
0A Bthrough variable through variable+ = (2.2)
where A and B are the two components being connected. These interactions have no
predefined direction, and are therefore non-causal.
Because each interaction point requires a separate port, our modeling framework is
limited to interactions that can be modeled as being localized at a finite number of points
on the boundary of the system. The framework further supports hierarchical model
structure with any number of levels in the hierarchy [41]. The hierarchy must be
terminated by primitive components that are described by declarative equations. These
equations establish differential-algebraic relationships between the variables of the ports
of the component.
Figure 2.1. A joint constraint captures the contact interaction between two rigid bodies A and B. CA and CB are the positions of the centers of gravity and P1 and P2 are the contact points.
24
2.4 Port-Based Modeling of Mechanical Systems
Rigid bodies in contact with each other are constrained in their motion by the nature of
the contact (Figure 2.1). The mechanical behavior of each rigid body is completely
described by the position and orientation of the body (across variables), and the forces
and torques acting on the body (through variables).
Since a rigid mass has only one set of across and through variables, it has a single
port. The constraint between a pair of rigid masses is captured in a joint component that
has two ports.
Two rigid body models are never connected directly to each other; they are connected
through a joint component. When the port on a mass component is connected to a port on
a joint component, a node is implicitly created, and the two ports in question are
connected to this node (Figure 2.2). Applied to the mechanical domain, node Equations
(2.1) and (2.2) become:
BABA RRpp == , (2.3)
and
Model for
AModel for
AModel for
BModel for
BModel for
JointModel for
JointP1 P2J2J1
N1 N2
Figure 2.2. The schematic shown in Figure 2.1 can be mapped into a port-based block diagram that captures the
system. Interaction of each block with other blocks is via ports, where energy flow takes place. Each block encapsulates a behavior model for that entity. A
25
0 ,0 =+=+ BABA FF ττ (2.4)
where through
ii
across
ii FRp τ,,,321 are the port variables for body BAi ,= . ip is the position vector of
body i, iR is the homogeneous transform describing the orientation of body i, iF is the
external force acting on body i, and iτ is the external torque acting on the body i.
In general, the internals of a component can be a behavioral model, or a sub-system
consisting of interconnected components, allowing for composable and hierarchical
models. The behavioral model of a component establishes relationships among the port
variables in the form of ODEs or algebraic equations (AEs).
2.5 The Composition in Simulation and Design (COINSIDE) Environment
2.5.1 Architecture
The implementation architecture of COINSIDE is similar to the Open Assembly
Design Environment (OpenADE) developed at NIST [74]. As is shown in Figure 2.3, the
DesignDatabase:
•Functional Model•Behavioral Model•Product Structure•CAD data•…
DesignDatabase:
•Functional Model•Behavioral Model•Product Structure•CAD data•…
CAD GUICAD GUI
Structure GUIStructure GUI
Function GUIFunction GUI
Behavior GUIBehavior GUI
Param. ExtractionParam. Extraction
Simulation EngineSimulation Engine
Data TranslatorData Translator
……
DesignDatabase:
•Functional Model•Behavioral Model•Product Structure•CAD data•…
DesignDatabase:
•Functional Model•Behavioral Model•Product Structure•CAD data•…
CAD GUICAD GUI
Structure GUIStructure GUI
Function GUIFunction GUI
Behavior GUIBehavior GUI
Param. ExtractionParam. Extraction
Simulation EngineSimulation Engine
Data TranslatorData Translator
……
Figure 2.3. Java-Based GUI components and services interact with the design data model.
26
core of our system is a central design data model in which the representations for the
current design are stored: function, behavior, product structure, and CAD data.
Furthermore, the data model contains the relationships between these representations; for
instance, if a system component implements a particular function, the data model will
contain a “has_function” relation pointing from the object to its functional model, and an
“implemented_by” relation from the model to the object.
During the design process, the information in the central data model is continually
transformed by autonomous software modules or by the designer— through graphical user
interfaces.
2.5.2 Data Model Modification Modules
Figure 2.4. Configuration editor GUI.
27
The main interaction between the designer and the data model occurs through the 3D
CAD GUI and the configuration editor GUI. The 3D CAD GUI is implemented using the
Java3D toolkit. It allows the user to view and manipulate the geometry associated with
the system components, and to define mechanical interactions between components. It
does not allow the geometry of individual components to be modified; we provide that
functionality by integrating our framework with Pro/Engineer. The Java-based 3D GUI is
still useful for system-level interactions that do not require the design of new components.
The configuration editor (Figure 2.4) provides a view of the system-level configuration.
Each of the system components appears in this view as a port-based block. The designer
connects the blocks to each other via ports. Some blocks can be hierarchical, and can be
expanded to view the subcomponents within the block. Such blocks have a “+” symbol in
the top left corner (Figure 2.4). A connection between two components also connects their
respective behavioral models via an interaction model that captures the physical
Figure 2.5. 3D viewer GUI.
28
interactions at the component interfaces. For example, Figure 2.4 shows the system-level
configuration for a train system [4].
The 3D viewer GUI (Figure 2.5) is a Java-based GUI that displays VRML models of
the components that are present in the configuration GUI. The viewpoint and geometry
can be manipulated using the mouse. In Figure 2.5, the geometry for the train system is
displayed.
The structure GUI (Figure 2.6) displays the assembly tree of the current system.
Subcomponents can be nested to arbitrarily deep levels. The designer can focus on
particular components by collapsing or expanding the appropriate portions of the tree.
Selecting a component in the tree also selects the component in the configuration GUI
Figure 2.6. Component repository GUI (left) and structure GUI (right).
29
and the 3D viewer GUI. In Figure 2.6, the tree structure for the train assembly is
displayed.
The repository GUI (Figure 2.6) displays the available components classified by
function or project. The repository is displayed as a tree, and nodes in the tree can be
collapsed or expanded to focus on a particular class of components. A component is
selected and added to the configuration GUI by selecting the component name in the tree
and pressing the “Add” button.
The parameter editor GUI (Figure 2.7) allows the designer to swap behavioral models
for each component, as well as assign parameters to the currently selected behavioral
model. Each component can contain multiple behavioral models at different levels of
detail, and one is chosen for simulation. For example, in Figure 2.7, the PID controller
sub-component of the power control system component of the train has been assigned the
“ideal” behavioral model and the corresponding parameters have been set.
2.5.3 Design Services
Figure 2.7. Parameter editor GUI.
30
In addition to the user interfaces, software modules interact with the design repository.
These modules can act as design assistants, working in the background. The tasks
performed by such modules include the following:
• the translation of CAD data to VRML format for rendering
• the compilation of behavioral models in XML format to Modelica and VHDL-AMS
simulation models.
• the extraction and verification of mechanical component interactions is a planned
addition to our software system.
The framework is implemented in a distributed fashion using Java and C++. The
coordination between the distributed software components is event-based [134]. When a
user or a software module modifies a portion of the design representation, the design data
model broadcasts an event to all the subscribing modules and GUIs. If necessary, these
components will then update their local cache to reflect the changes in the design data
model. This allows us to maintain consistency between the internal design data and its
presentation to the user.
Because of its distributed implementation, our framework can also serve as a tool for
collaboration. Multiple users can interact with the same design simultaneously, and
design modifications introduced by one user can be propagated immediately to all other
users.
31
2.5.4 Event-Based Synchronization
A change introduced in one aspect of the system-level data model can impact other
aspects. For example, a change in the geometry of the body of the train will alter the
parameters of the mechanical behavioral model of the train, as well as the VRML
representation of the train. As described in Section 2.5.1, the data model maintains the
relationships between these aspects.
We use event-based synchronization to communicate these changes across the
GUIs. COINSIDE registers all relationships between the GUIs. An event in a GUI is
synchronized with all other impacted GUIs.
Figure 2.8. Modelica behavioral modeling GUI.
32
2.5.5 Simulation Engine
At simulation time, the XML representation of the configured components is translated
into the target simulation language Modelica [89] or VHDL-AMS [70]. In this thesis, we
will use Modelica in all the examples and in the case study. The behavioral modeling GUI
in Modelica is very similar to the COINSIDE configuration GUI, with icons for behavioral
models and lines connecting model ports (Figure 2.8).
The Modelica representation is optimized and then converted into C procedures by
the Dymola Modelica solver [44]. The coupled differential-algebraic system is solved over
time. The designer can view a time series plot of any of the model variables (Figure 2.9).
Based on this feedback it is possible to refine the system-level model within COINSIDE.
2.6 Summary
To support virtual prototyping, we have developed a simulation and design environment in
which design and modeling are tightly integrated. This integration is based on
Figure 2.9. Modelica time-series output.
33
composition of system-level components via ports. By composing components into
systems, the design team simultaneously designs and models new artifacts.
To enable this composition we use a modular port-based modeling paradigm that also
facilitates the reconfiguration of models. The ports capture energy exchange between the
interfaces of the connected components.
The research presented in this chapter is only an initial step towards an integrated
framework for simulation-based design. Our current implementation is called COINSIDE
and is limited to component models with lumped interactions and fixed interfaces. We
have successfully applied it to applications in the mechatronics area. However, to
carefully evaluate its expected benefits in terms of component reuse and a faster, less
expensive design cycle will require significant further research.
Additional research is also needed to expand the functionality of the framework. The
selection of an adequate level of detail for simulation models requires further expansion of
the capabilities of our framework. We currently provide the capability to include models at
different levels of detail in reconfigurable models, but have not yet addressed the issue of
aiding the user in selecting the most appropriate model for a particular simulation
experiment— the model that has adequate accuracy and requires minimum computational
resources. Finally, to allow very detailed analyses, finite-element models need to be
included in our framework. Future research should focus on the interfacing between finite
element models and lumped models so that we can includes models of distributed
physical phenomena such as mechanical flexure, or complex electromagnetic and thermal
behavior in system-level models.
34
3 An Attribute-based Representation for
Systems3
3.1 Introduction
The system-level design process is usually top-down. The designer begins with a high-
level functional description that is decomposed into sub-functions. Sub-functions are either
decomposed further into other functions, or are assigned to components. The component
contains design data and simulation models. When further decomposition or component
assignment is not desired, the designer composes the components to realize the high-
level virtual prototype. In this process, there are three recurring themes: composition, or
combining subcomponents to create a compound component; reuse, or replacing a
component with another of similar or identical function; and iteration, or extending the
definition of a component to select or create a more specific component.
3 This chapter is partly based on the paper:
• Sinha, R.; Paredis, C.J.J.; and Khosla, P.K., “Automatic Behavioral Model Composition in Simulation-Based Design”, Proceedings of the 35th Annual Simulation Symposium, April 14-18 2002, San Diego, California, USA, to be presented.
All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you
can't get them together again, there must be a reason. By all means, do not use a hammer
IBM maintenance manual, 1925
Grammar and logic free language from being at the mercy of the tone of voice. Grammar protects us against misunderstanding the sound of an
uttered name; logic protects us against what we say have double meaning. Rosenstock-Huessy
35
In this chapter, we posit that the components, functional models, CAD models and
behavioral models can be represented using a common framework, namely hierarchical
attributes that represent a complete description of these entities. We define attribute
grammars that govern how physical interactions between components can be composed,
reused or refined during the design process. We show that our approach overcomes many
of the limitations of taxonomies and product hierarchies.
We do not attempt a complete attribute-based description of all design entities. We
focus on the ports and interaction models in the design. Interactions are the physical
phenomena that occur at the interfaces between connected components (Figure 3.1).
Most of the research in systems design has focused on modeling components and their
use in configurations. To automatically convert the configuration information to a
simulation model, the interaction dynamics must also be captured in behavioral models.
Researchers have not paid much attention to capturing the dynamics of the interaction
phenomena.
In our framework, all interactions between components are mediated by ports. To
represent these ports, we introduce port attribute grammars that form the basis for other
attribute grammars for components, interaction models and functional models (Figure 3.2).
ComponentsComponents
Physical Objects
Screws, Motors, Pumps,Pistons etc.
Interactions BetweenPhysical Objects
Joints, Springs, Dampers, Contact Resistances,
Junctions etc.
Interactions BetweenPhysical Objects
Joints, Springs, Dampers, Contact Resistances,
Junctions etc.Component Objects
Component Interactions Figure 3.1. System-level components are of two types - component objects and component interactions
36
In this thesis, we focus on attribute grammars for ports and interaction models. Our
formalism supports automatic instantiation of interaction models given the types of the
connected ports, as well as the ability to replace one interaction model for another
depending on the required accuracy of the desired simulation experiment.
Our attribute-based framework supports the following aspects of the design process:
Composition. In our framework, design and system-level simulations are created by
composition of component objects [106]. Using the attribute grammars, we compose
component objects by composing their constituent attributes.
Organization. The entities used in the design are ports, component objects,
component interactions, and CAD models [106], as well as functional models. They should
be classified and organized so that the designer is not inundated with choices. We provide
a set-theoretic formalism to organize these design entities.
Reuse through standardized representation. A library of design entities can be
indexed by their attributes. Candidate entities can be selected by searching the library for
particular attribute-value pairs.
Design iteration. In our framework, the design process iterates between selection
and composition of components, and evaluation of their behavioral models in simulation.
During each iteration, the designer uses components and models that are different in
topology and/or complexity from the previous iteration. Our attributes-based framework
supports transitions between design iterations by the addition or subtyping of attributes.
In this thesis, the focus is on laying the foundation for representing designs and
models using attributes. We characterize, model and organize the interactions between
components using attributes and attribute grammars for ports and interaction models
37
(Figure 3.2), and we leave the attribute representations for component objects and
functional models for future research. We have implemented the grammars using Java
and XML, and we illustrate our framework with a simple example.
3.2 Attribute Grammars in System-Level Design
Several researchers have investigated the applicability of formal grammars in
mechanical design [9, 28, 55, 97]. Design can be viewed as a sequence of
transformations, beginning from a functional requirement and culminating in a physical
device. The space of possible designs is very large possibly infinite.
Formal grammars offer a very compact representation of a very large space such as
the design space. Every point in the space is represented as a string in a language.
Formal grammars are computational procedures that generate and parse the strings in the
language.
However, there has not been a significant effort to formalize the representation of
system-level design and simulation. We have developed attribute grammars for ports and
interaction models in system-level designs. In this section, we discuss the important
Attribute Formalism
Component Grammar
Port GrammarProduction
RulesPort
AttributesAttribute
Constraints
InteractionModel
Grammar
FunctionalModel
Grammar
Set theory, OO
System-Level DesignXML Document
XM
L D
TDs
XM
L
Attribute Formalism
Component Grammar
Port GrammarProduction
RulesPort
AttributesAttribute
Constraints
InteractionModel
Grammar
FunctionalModel
Grammar
Set theory, OO
System-Level DesignXML Document
Attribute Formalism
Component Grammar
Port GrammarProduction
RulesPort
AttributesAttribute
Constraints
InteractionModel
Grammar
FunctionalModel
Grammar
Set theory, OO
System-Level DesignXML Document
XM
L D
TDs
XM
LX
ML
DTD
sX
ML
Figure 3.2. Attribute Grammars in System-Level Design
38
properties of grammars and attribute grammars, the applicability of attribute grammars to
design, and their extension to system-level design and simulation.
3.2.1 Formal grammars
Strings represent a point in the design space and consist of a finite sequence of
symbols from the alphabet of the formal grammar. The alphabet consists of terminal
symbols. Production rules operate on the symbols to generate strings. The language also
permits empty strings.
A grammar defines a language. It consists of an alphabet, a set of production rules and
a starting symbol. Chomsky [32] defnied a hierarchy of grammars that impose different
restrictions on the production rules [68]:
Type 0: Such grammars have no restrictions on the production rules. These grammars
are the most powerful for string generation. However, it is not possible to use a type-0
grammar to determine whether a particular string can be transformed into another. Such
grammars are also known as unrestricted grammars.
Type 1: These grammars contain only rules of the form a b→ . The lengths of a and b
are constrained such that a b≤ . They are known as context-sensitive grammars (CSG).
Type 2:These grammars contain only rules of the form a b→ where a b≤ and a is a
single non-terminal. They are known as context-free grammars (CFG).
Type 3: These grammars contain only rules of the form a b→ where a b≤ and a is a
single non-terminal and b is a terminal, non-terminal or a terminal followed by a non-
terminal. They are also known as regular grammars.
39
Applications of grammars are grouped based on two major properties: verification
(membership) and synthesis (generation). In this thesis, we are primarily concerned with
the verification problem: we must ensure that a new port or interaction model conforms to
certain rules that we define in the grammar. The membership problem is of order ( )nO e
for CSGs, ( )3O n for CFGs and ( )O n for regular grammars [97]. See Revesz [114] for a
more detailed description of formal grammars.
3.2.2 Attribute grammars
In attribute grammars [76], a context-free grammar is augmented with attributes, and
the production rules can specify constraints over the attribute values. The attributes are
used to establish the meaning or semantics of a string in the language. In Figure 3.3, the
grammar specifies the north, south, east and west Cartesian motions that are possible in a
plane. The terminals are N , S , E and W . The non-terminals are path and step . The
path non-terminal has two attributes associated with it, namely Ex and Ey . They capture
Grammar Production Rules
pathpath step pathstep Nstep Sstep Estep W
ε→→ ∧→→→→
Attributes
.
...
path Expath Eystep xstep y
∆∆
1 2 2
. 0 . 0. . . . .
. 0 . 1
. 0 . 1
. 1 . 0
. 1 . 0
path Ex path Eypath Ex step x path Ex step y path Eystep x step ystep x step ystep x step ystep x step y
= ∧ == ∆ + ∧ ∆ +
∆ = ∧ ∆ =∆ = ∧ ∆ = −∆ = ∧ ∆ =∆ = − ∧ ∆ =
Figure 3.3. An attribute grammar to generate Cartesian motion [24]. The subscripts 1 and 2 are used to differentiate between the two path attributes.
40
the (x,y) coordinate of the point in the Cartesian plane. Similarly, step has two attributes:
x∆ and y∆ , that capture the current displacement associated with the step in the plane.
The attributes are related via the production rules. The equivalent DTD and the XML to
generate a motion string of “EEN” (two steps East and then 1 step North) is shown in
Figure 3.4.
Attribute grammars facilitate the interpretation of formal languages and have been
used extensively in this application domain [36-38, 51]. They have been used to
automatically synthesize electronics hardware [45], for product configuration [65], and
shape generation [125].
We represent our attribute grammars using XML and Java. An XML DTD [155] is a
representation of an attribute grammar. XML tags correspond to symbols. A tag that is not
composed of other tags is a terminal symbol. XML attributes associated with a tag are
equivalent to attributes in the grammar. Constraints between attributes are captured as
attributes and interpreted in our Java-based software.
Equivalent DTD Example XML for string “EEN”
<?xml version="1.0" encoding="UTF-8"?> <!-- Cartesian movement grammar Possible movements are: N, S, E, W--> <!ELEMENT path (step, path)* > <!ELEMENT step (N | S | E | W) > <!ELEMENT N EMPTY > <!ELEMENT S EMPTY > <!ELEMENT E EMPTY > <!ELEMENT W EMPTY > <!ATTLIST path Ex CDATA #REQUIRED > <!ATTLIST path Ey CDATA #REQUIRED > <!ATTLIST step Dx CDATA #REQUIRED > <!ATTLIST step Dy CDATA #REQUIRED >
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE path SYSTEM "example-grammar.dtd"> <!-- Instance "EEN" of the Cartesian movement grammar --> <path Ex="2" Ey="1"> <step Dx ="1" Dy="0"> <E/> </step> <path Ex="1" Ey="1"> <step Dx ="1" Dy="0"> <E/> </step> <path Ex="0" Ey="1"> <step Dx ="0" Dy="1"> <N/> </step> <path Ex="0" Ey="0"> </path> </path> </path> </path>
Figure 3.4. XML representation of the attribute grammar in Figure 3.3. The production rules are not represented in the DTD.
41
3.2.3 Grammatical representations for design
Applications of grammars in engineering design fall into two categories: verification
and synthesis. The purpose of the grammar determines the relative importance of a
property [97]. Grammars that are used for verification of the correctness of a design need
to parse a string efficiently. On the other hand, grammars that are used to synthesize
design alternatives need to be unambiguous.
Another layer of complexity can be added in associating the symbols of the grammar
to their design counterparts [97]. It is possible to obscure the original design specification
by rewriting the grammar to make it more efficient. We address this issue as well as the
problem of ambiguity in our formalism (Appendix A).
Our grammars formalize system-level design. We use the grammars to verify that the
design conforms to our rules throughout the iteration of the design. We also use them to
select components and models that match library searches. Searching of our component
and model libraries is supported by retrieving all entities that match user-specified
attribute-value pairs.
3.3 A Set-Theoretic Approach to Configuration Design and Simulation
The building blocks within our composable simulation and design environment are
component objects and component interactions [106]. These objects consist of a
configuration interface (a list of ports), CAD model(s), behavioral model(s), and
relationships between them. In set-theoretic terms, we can define a design D as a set of
unique attributes. This definition allows us to represent components and models as
collections of attributes, such that composition of components results in a system-level
42
design represented by the composition of the individual attribute representations. Two
component objects C1 and C2 are composed given their connectivity information p by
concatenating their attribute representations.
To achieve the interleaving of design and simulation, the behavioral models of the
component objects must also be composed when their components are composed. As
explained in the subsequent sections, a direct application of Kirchhoff’s Law to the ports of
the behavioral models results in incorrect models. We solve this problem by introducing
the concept of interaction models that capture the dynamics of the physical interaction
between the component objects. When components C1 and C2 are composed via their
ports, their corresponding behavioral models M1 and M2 are also composed via an
interaction model I. I is chosen within our framework based on the attributes of the
connected component objects.
A very useful aspect of set theory is the Separation Theorem [119]. The theorem
defines the partitioning of sets based on a boolean-valued criterion, called a predicate. In
the context of simulation-based design, this amounts to identifying those design entities
from a space (or set) of design entities that possess some property. A succession of such
identification operations is equivalent to evolving the design from a simple to a more
complex representation. We apply this theorem to support iteration of ports and
component interaction models.
An attribute-based approach to models and design entities for simulation-based design
is better than a traditional taxonomy-based approach. Firstly, instead of explicitly relating
models to each other via a tree structure, we are able to describe a model by its
characteristics. Secondly, taxonomies are not able to capture multiple-inheritance very
43
well. In our framework, a model that is a child of two or more parents is defined as
possessing at least all the attributes of all its parents. Finally, when creating new models,
the designer does not have to worry about placing the models in the framework. He
merely defines its inheritance relationships and any additional attributes that it may have,
and the framework handles the storage and retrieval of the new model.
Our framework uses several design entities, namely ports and interaction models, and
we introduce these entities before describing their grammars.
3.4 Ports
A port is a descriptor for a location on the boundary of a component where the
component interacts with its environment. In Figure 3.5, ports 1 and 3 represent point
interactions, whereas port 2 represents a distributed interaction that is lumped at the port.
There are two types of ports used in COINSIDE: configuration ports and modeling
ports. We describe each type here.
Widget1
23
Widget1
23
3
2
1
Widget
3
2
1
Widget
Figure 3.5. Ports on a component object.
44
Configuration ports capture connection semantics between a component and its
environment. For example, a DC motor component has four ports, two electrical ports, a
shaft port and a stator port. The electrical ports correspond to the electrical connectors of
the motor, the shaft port to the rotor and the stator port to the stator. A gear component
has ports for its teeth and shaft. The gear shaft port is connected to the motor shaft port
and is related to a mechanical modeling port that provides a transform for the rotational
axis of the gear. The gear teeth port connects to another gear teeth port to form a gear
pair, and provides information like the number of teeth and the gear pitch radius via a
feature port. Configuration ports can be aggregated to form more complex ports at higher
levels of abstraction.
Modeling ports capture the energy exchange between behavioral models. Each
connection between two behavioral models imposes some constraints on the variables of
the modeling port. For a connection between simple energy or mass ports (such as
mechanical, electrical, thermal and hydraulic ports), these constraints are the equivalents
of the Kirchhoff voltage and current laws in electrical circuits. For signal ports, the
constraint equates the value of the signal at each end of the connection.
There is a 1-many relationship between a particular configuration port and its
corresponding modeling ports. For example, a gear configuration port is related to its
corresponding 3D mechanical modeling port. This relationship is captured within the
component object.
45
3.5 Parameters
A parameter is a quantity whose value characterizes a member of family of
components or behavioral models. Parameters, along with ports, form the configuration
interface for a component or behavioral model. The component or behavioral model is
completely specified when all its parameters are provided.
Some parameters – the instantiation parameters – are provided by the designer when
a component is used in a system-level model. For example, consider a family of resistor
components that is parameterized by the resistance parameter. The value of the
resistance parameter must be provided before the resistance component can be
instantiated and used in a configuration.
Another type of parameter is the behavioral model parameter. The instantiation
parameters are related to parameters that are used in the behavioral models [130].
Particular CAD features from the CAD specification of a component can be used as
parametric input to the behavioral model. For example, a family of gear components can
contain a parametric CAD model specification of the gear, and a parametric behavioral
model. The CAD model has parametric teeth features (such as number of teeth and
pressure angle) that are used to parameterize the behavioral model.
Parameters are either provided by the designer or extracted from other parameters.
For example, in subsequent chapters we will describe how mechanics behavioral model
and interaction model parameters can be extracted from CAD models.
46
3.6 COINSIDE Grammars
3.6.1 Port Grammars
Ports form the basis of our framework. They are a part of the interfaces for component
objects, component interactions, and behavioral models. In previous sections, we defined
a port as a discrete point of interaction between a component and its environment. By this
definition, a port is the spatial quantum of interaction in our framework.
At a specific, physical location on the interface, there can be exactly one port.
Therefore location becomes the organizing principle of a port. The geometry and material
properties at the location become required attributes of every port. We model the location
using a CAD feature, and material properties by a set of defining attributes such as name
and physical properties (Figure 3.6).
Another required attribute is the Intended Use attribute. This attribute captures all the
intended functions for the port as defined by the designer. The energy and informational
domains of the port are also contained within this attribute. In addition, any special
compatibility constraints on any connections to this port are specified here.
Location
Port
CAD FeatureMaterial
NameProperties
Young'sModulusDensity
Intended Use Figure 3.6. Attribute representation of a port.
47
We formalize these ideas through axioms in the port formalism (Appendix A). Here we
discuss some of the important axioms (Figure 3.7) and their effect on the representation
and use of design entities. A partial grammar for ports is illustrated in Figure 3.8. The
corresponding attributes and their meaning is presented in Figure 3.9. The production
rules that constrain the values of the attributes are captured within COINSIDE as Java
methods.
The Universality Axiom requires all interactions between components to occur through
ports. This allows us to define the interface of a component as consisting of a set of ports.
The Uniqueness Axiom requires the ports of a component or model to be uniquely
identifiable using an identifier.
The Orthogonality Axiom requires that attributes be independent of each other. This
reduces the ambiguity in the grammar by not allowing an attribute to be expressed as a
combination of other attributes. Therefore, a design specified using the grammar has a
unique representation string.
The Finiteness Axiom states that a port consists of a finite number of attributes. Infinite
attribute ports are difficult to capture using an attribute grammar. Currently, our framework
permits only ports with a finite number of attributes. We leave the modeling of field
interactions with potentially infinite ports to future research.
Axiom 1: All interactions occur through ports. (Universality Axiom) Axiom 2: The ports in the interface are ordered (Uniqueness Axiom) Axiom 3: All attributes are independent of each other (Orthogonality Axiom) Axiom 4: An attribute is modeled as a finite set of non-terminals (Finiteness Axiom). Axiom 5: Every configuration port type has at least one compatible port type (Compatibility
Axiom) Axiom 6: If the set of attributes of two ports are identical, then the two ports are identical
(Identity Axiom) Figure 3.7. Important axioms in the port formalism.
48
The Compatibility Axiom states that when a connection is made between two ports, the
ports must be compatible with each other. For example, the tire-road port on a tire
component of a car is compatible with the running surface port of the road. Port
compatibility is established as a constraint relation over the Intended Use attributes of the
two ports.
The Identity Axiom establishes the equality relation over ports. Ports are equal when
their constituent attributes are identical.
? ?
? ?
location - --
- volume-density resistivity- -- - - - -
port material intended use other attributesmaterial property listproperty listintended use function listfunction list roll on surface provide rolling surface tr
→→
→→→ ?
| | | | |
-- - -
- - -- -
- mechanical electrical thermal fluidic signal software
ansmit powerroll on surface energy domainprovide rolling surface energy domaintransmit power energy domainenergy domain
→ +→ +
→ +→
Figure 3.8. Partial port grammar.
Attributes Description Location.name Name of the location of the port Location.CAD_model The CAD model/feature associated with the location Material.name The name of the material at the location Material.description A description of the material volume-density.symbol The symbol for volume density volume-density.units The units of volume density Resistivity.symbol The symbol for resistivity Resistivity.units The units of resistivity roll-on-surface.name The name of the non-terminal roll-on-surface.description A description of the non-terminal Provide-rolling-surface.name The name of the non-terminal Provide-rolling-surface.description A description of the non-terminal Transmit-power.name The name of the non-terminal Transmit-power.description A description of the non-terminal Transmit-power.constraints Constraints on the transmission of power
Figure 3.9. Attributes for the partial port grammar in Figure 3.8.
49
Using these axioms and other definitions stated in our formalism, the designer can
select, instantiate, iterate and connect ports (Figure 3.10). The connection between ports
has dynamics that are captured in the grammars for the component interaction models.
3.6.2 Interaction Model Grammars
Component interaction models capture the dynamics at the interfaces between
component objects. As described in subsequent chapters, we represent the interaction as
a collection of behavioral models aggregated into the interaction model container. The
container and the behavioral models within map to a set of sets of attributes. Operations
on the models, such as instantiation, subtyping and iteration, are performed by production
rules in the grammar. We do not present the entire grammar here. Instead, we highlight its
important features and their applicability in the design process.
Figure 3.10. Attribute grammar GUI
50
One important feature is our adaptation of the Separation Theorem. Using Theorem 1
(Appendix A), we can iterate interaction models from simple to more complex models. This
is accomplished using the REPLACE() predicate (Appendix A). This predicate constrains
the replacement model to have ports that are supertypes of the original ports. For
example, a train-track interaction model with a purely mechanical interaction can be
refined to another model with a mechanical and an electrical interaction.
The designer can extend the grammar by following a few simple rules. When adding a
new interaction model, the designer must consider three important characteristics of
interaction models: domains of applicability, number and nature of phenomena, and times
of interaction (Figure 3.11).
The new interaction model captures the dynamics of physical phenomena in a single
domain, or across domains. Some interactions like a kinematic joint are single-domain
interactions, because they represent a single domain interaction, namely the mechanical
domain. Others are cross-domain interactions, like the electromechanical energy
conversion in a motor.
51
One or more physical phenomena can occur in an interaction. Simple interactions like
a kinematic joint capture only a mechanical interaction. More complex interactions like that
between an electrical train and its running track include several physical phenomena such
as mechanical, electrical and signal interactions.
Another important aspect of an interaction model is its time characteristics. Some
phenomena occur continuously over time, such as a kinematic interaction. Others are
events at discrete points in time, such as mechanical collisions. The former can be
modeled with differential and algebraic equations. The latter can be modeled using finite
Does the Interaction occurat specific times, orcontinuously ?
Does the interaction occur in asingle domain or across multipledomains ?
How many different physical andinformational phenomenaparticipate in this interaction ?
Interaction
Time
Phenomena
Domains
Single-domain
Kinematics
Cross-domain
Electrothermal
Electromagnetic
Electromechanical
Continuous
Discrete
MechanicalCollision
Single
Mechanical only
Multiple
Mechanical+Electrical
Electrical+Signal
Most others
Figure 3.11. Required attributes for interaction models.
52
state machines or software algorithms. All these aspects are captured as attributes in our
grammar.
Other attributes that are used in our grammar include the parameters for the model,
the equations of the model, any assumptions made, etc. Some of the attributes represent
constraints over other attributes, such as the assumptions attribute.
3.7 Illustrative Example
To illustrate the concepts developed in the previous sections, we use an example of a
complex electromechanical system – a train system. We will use this simple example to
illustrate concepts developed in this chapter and in the next two chapters. In the interest of
brevity, and given that the focus of this chapter is on ports and interactions, we will focus
on the interaction between the train and its track (Figure 3.12). We will use the port and
interaction model grammars to demonstrate automatic selection, abstraction and design
refinement of ports and interaction models.
In a real-world train-track interaction, there may be hundreds of physical and
informational interactions between the train and the track, such as mechanical interactions
between the train and the track, electrical power flows, command signals, and sensor
signals, as shown in Figure 3.12.
TrainTrain…
Track
…
Track
…Mec
hpo
rt
sign
alpo
rt
Elec
port
Train
Track
Aggregate Port
Figure 3.12. Abstraction of a train-track interaction. Each block represents a component in the configuration
layer, and a circle represents a port on the component interface.
53
The train-track port is an aggregation of two ports – a wheel port and a brush port. This
captures the mechanical, and electrical and control interaction, respectively, between the
train and the track. At this early stage of the design process, the port is described as
shown in Figure 3.13. This is a high-level description that is augmented with attributes
later on in the design process.
The train-track interaction port has two sub-ports, but in this example we only consider
interaction models for the mechanical behavior of the train along the track. Ports on the
interaction model are related to ports in the configuration using the formalism (Figure
3.14).
To obtain a more realistic virtual prototype, further refinement is necessary in the train-
track port. This requires elaborating the train-track port and interaction model by adding
attributes.
Train-track Port
Brushes Port
Wheels Port Figure 3.13. Train-track Port
54
The train-track port is also iterated to a semantically richer definition. By following the
rules of our formalism, the iterated train-track port of Figure 3.13 now is changed to the
port of Figure 3.15. The new port now has location and material attributes for the wheel
that define the running surface of the wheel as the interaction point. In addition, the brush
port has location and material attributes for the brush-central rail contact surface. Both the
wheel and brush port have intended use attributes that are compatible with the
corresponding intended use attributes on the track.
Train Track
IM Container
Mechanicalonly
Electrical only
Signal only
Mechanical only
Electrical only
Signal only
Mechanicalonly
Electrical only
Electrical only
Signalonly
Primitive IM
Aggregate IM
TrainTrain TrackTrack
IM Container
Mechanicalonly
Electrical only
Signal only
Mechanical only
Electrical only
Signal only
Mechanicalonly
Electrical only
Electrical only
Signalonly
Primitive IM
Aggregate IM
Figure 3.14. Port maps for the train-track interaction model.
55
Using the formalism, the train-track interaction port is refined to two sub-ports that are
connected together on either high-level component. These ports are the wheel port
(mechanical port), and the brush port (control and DC electrical port). With the train being
modeled in CAD as a detailed solid object, a train-track interaction model can be
automatically derived from the geometry. The parameter extraction algorithms examine
the current CAD model for the train and track components, obtains the material properties
and wheel geometry and uses a look-up table to obtain the friction coefficient for a
coulomb friction model. This completes the attribute-based specification of the interaction
model (Figure 3.16).
Intended Use
Material
Wheels Port
Wheel Port (Front Left)Location
Wheel Port (Front Right)Wheel Port (Back Left)Wheel Port (Back Right)
Active DomainsElectricalMechanicalSignalThermalHydraulic
Tire
Width = 0.3 mPressure = 3 atm
Intended Use
Material
Brushes Port
Brush Port (Left)Location
Brush Port (Right)
Active DomainsElectricalMechanicalSignalThermalHydraulic
Brush
Contact Width = 0.1 mSide = Left
Intended Use
Material
Wheels Port
Wheel Port (Front Left)Location
Wheel Port (Front Right)Wheel Port (Back Left)Wheel Port (Back Right)
Active DomainsElectricalMechanicalSignalThermalHydraulic
Tire
Width = 0.3 mPressure = 3 atm
Intended Use
Material
Brushes Port
Brush Port (Left)Location
Brush Port (Right)
Active DomainsElectricalMechanicalSignalThermalHydraulic
Brush
Contact Width = 0.1 mSide = Left
Figure 3.15. Wheel and Brush Port.
56
Material
Modeling Ports
Wheel-Track InteractionModel
Assumptions
Parameters
Active DomainsElectricalMechanicalSignalThermalHydraulic
Location
Geometry
Invariant = TRUE
Wheel Width = 0
Port Map 1 = Wheel Port :: Mechanical Port
Intended Usesroll-on-surfaceabsorb-shockmagnify-torquetransmit-DC-power
Invariant = TRUEReactive = FALSE
Equations
Physical Phenomena
Friction
Kinematic constraint equations
( ) ( )11 2 1c r sv k k k vω−= + +r r r
( )( )
1 1 1 1 1 1
2 2 2 2 2 2
c s
s c
r c v c v
a r c v c
ω ω ωω ω ω
+ × + × + × − =+ + × + × + ×
r r r r r r r r&& &r r r r r r r r&& &
Dynamic constraint equations
1 2F F=r r
1 2τ τ=r r
Port Map 2 = Track Port :: Mechanical Port
Coulomb friction coefficient = 0.2
Parents = NIL
Figure 3.16. Wheel-track interaction model for the train.
57
3.7.1 Discussion
In this example, we have used our attribute-formalism to select and iterate ports and
interaction models. Attribute-based representations allow us to define ports and models by
their characteristics, rather that by their position in a taxonomy.
In the design iteration, we have used abstraction, both port and for interaction models.
Abstraction serves an important purpose: to reduce the amount of detail presented to the
designer so that he or she can focus on high-level modeling decisions without dealing with
small details.
Our framework supports automatic interaction model selection and instantiation. The
automation allows the designer to focus on the more important tasks of configuration and
CAD and behavioral model parameter assignment, while accurately capturing the intended
interactions between components in the configuration. The automation also maintains
consistency between the CAD parameters and behavioral representations.
Separation of the interfaces from the content of models (whether behavior or
configuration) has the added advantage of encouraging standardization and reuse of
these models in later design projects.
58
4 Component Objects4
4.1 Introduction
Creating high-fidelity simulation models is a complex activity that can be quite time-
consuming. To take full advantage of virtual prototyping, it is necessary to develop a
modeling paradigm that supports model reuse, that is integrated with the design
environment, and that provides a simple and intuitive interface which requires a minimum
of analysis expertise. This chapter introduces such a paradigm, composable simulation
and design, which is based on model composition from system components [106].
Many products have a modular architecture that is based on the selection and
composition of off-the-shelf components and components reused from older designs.
When the new design is created, components are selected and then connected together
in a configuration (Figure 4.1).
4 This chapter is based on the following published papers:
• Paredis, C.J.J; Diaz-Calderon, A.; Sinha, R.; and Khosla, P.K., “Composable Models for Simulation-Based Design”, Engineering with Computers, 17(2):112-128, 2001.
• Sinha, R.; Paredis, C.J.J.; and Khosla, P.K., “Integration of Mechanical CAD and VHDL-AMS Behavioral Modeling”, Proceedings of IEEE/ACM BMAS 2000, Orlando, FL, USA.
The first rule to tinkering is to save all the parts. Paul Erlich
Every contrivance of man, every tool, every instrument, every utensil, every article designed for use, of each and every kind, evolved from a very simple
beginning. Robert Collier
59
We call these building blocks component objects. Component objects are composed
into systems by connecting the ports in their configuration interfaces. Our framework
supports the use of component objects in the following ways:
Composition. In our framework, design and system-level simulations are created by
composition of component objects. Component objects are composed through their ports,
as described in the previous chapter.
Organization. The entities within a component object are ports and parameters,
behavioral models, and CAD models, as well as functional models. They should be
classified and organized so that the designer is not inundated with choices. We provide a
set-theoretic formalism to organize these design entities.
Design iteration. In our framework, the design process iterates between selection
and composition of components, and evaluation of their behavioral models in simulation.
During each iteration, the designer uses components and models that are different in
topology and/or complexity from the previous iteration. Our attributes-based framework
supports transitions between design iterations by the addition or subtyping of attributes.
InterfaceInterface
Interface
Component A Component B
Behavioral Model
Behavioral Model
Contained-in
BehaviorPort
Connection
Con
figur
atio
nM
odel
ing
ComponentPort
Interface
Behavioral Model
Behavioral Model
Contained-in
BehaviorPort
Figure 4.1. Design as a process of configuration of components and selection of behavioral models for the
components and connections.
60
4.2 Component Objects
A component is a modular design entity with a complete specification describing how
it may be connected to other components in a configuration. For example, a DC motor
component has a shaft to connect it to a drive-train, and bolts that fasten it to a platform.
The shaft and the bolts collectively form the ports or interface of this component.
As shown in Figure 4.2, a component is instantiated in the design by specifying
instantiation parameters that describe its specification. Once instantiated, it is connected
to other instantiated components via its ports. Before simulating the design, the designer
selects behavioral models from the behavioral model container that describe its physical
behavior, and CAD models from the CAD model container that specify how it may be
manufactured and visualized.
A configuration is created when two or more components are connected to each other
via their interfaces. A component can itself encapsulate a configuration of components,
thus allowing for the hierarchical description of systems (Figure 4.2). We use the
configuration information to automatically generate system-level simulation models.
ComponentConfigurationConfiguration Interface
InstantiationParameters
CAD Model Container
Behavioral Model Container
CADSpecification
Figure 4.2. Components may encapsulate configurations of sub-components.
61
The components are connected to other components via configuration ports. For
example, consider the configuration where a DC motor component is connected to a gear
component. The DC motor component has ports for the rotor shaft and the stator, and the
gear component has ports for the gear teeth and the gear shaft hole. The connection is
established by connecting the “rotor shaft” port on the motor to the “gear shaft hole” port
on the gear. The configuration ports used in this example are defined in abstract terms,
and no information is available about the semantics of the connection that they establish.
The configuration ports are related to modeling ports in the modeling layer. These
modeling ports make up the interface of the behavioral models related to the component.
4.2.1 Behavioral Models
Behavioral models capture the mathematical description of the physical and
informational behavior of a component. For the scope of this research, we consider these
models to consist of either differential-algebraic equations (DAEs) for continuous time
phenomena, or discrete event systems specifications (DEVS) [165]. Behavioral models
can also be composed out of other behavioral models through the port-based modeling
paradigm [42].
62
A component object can contain multiple behavioral models with different levels of
detail. For example, a DC motor component can contain a family of mechanical behavioral
models. One model could only capture the kinematic constraints between the rotor and
the stator, while another could include non-linear friction models.
All of these behavioral models are stored in a behavioral model container. The
container is separated into three parts: a family of interfaces, a family of implementations
of particular models per interface, and a set of 2-tuples that enumerate the
correspondences between the interfaces and implementations (Figure 4.3). One of these
2-tuples is the default map, and determines the default interface and implementation for
the behavioral model. The implementation is typically a mathematical description of the
DAEs and DEVS that make up the behavior of the component. Behavioral models in our
framework are represented using the Modelica simulation language [89].
4.2.2 CAD Models
A CAD model describes the geometry, relative positions and material properties of the
parts that make up the design. Depending on the simulation experiment, the geometric
Behavioral Model ContainerImplemen-
tationImplemen-
tationInterfaceInterface
Interface-Content MapsDefault
Figure 4.3. A behavioral model container containing behavioral models. Behavioral models describe the
physical or informational behavior of a component.
63
representation may be simple (for bounding-box experiments), or complex (for detailed
design or manufacturing). Our framework provides the ability to use a CAD model
container that contains CAD models at multiple levels of detail.
The CAD model container (Figure 4.4) captures all the necessary CAD-related
information in the design. It contains an interface and several CAD models. The ports of
the interface correspond to geometric or material features that are exported to other parts
of the design representation, such as behavioral models. For example, the mass of the
CAD model could be one such feature that is used in a Newtonian mechanics behavioral
model.
Modern CAD modeling systems like Pro/ENGINEER [110] represent a CAD model
using feature trees that capture all the relevant characteristics of the design. By including
evaluation procedures as features in the feature tree, one can automatically perform
behavioral analysis whenever a part or assembly is modified [43]. For example, a mass
computation procedure would use the CAD model and the material density to compute the
mass of the design. Given the maturity of this capability, we do not develop attribute
grammars for CAD models. Instead we connect our framework with Pro/ENGINEER so
CAD Model Container
CADData
Interface
CAD Model Container
CADData
InterfaceInterface
Figure 4.4. CAD model container.
64
that we can use the feature modeling capability. In this research, we focus on developing
attribute grammars for ports and interaction models.
4.3 Derivation of the Behavioral Model from CAD Data
Composable simulations are based on the concept of component objects that
combine form and behavior. By composing component objects into systems, a designer
simultaneously designs and models new artifacts. The previous section introduced a
modular modeling paradigm that supports such composition. In this section, we focus on
checking that these behavioral models are consistent with the corresponding form
descriptions as represented by a CAD model.
A component object contains a description of the form of the component as well as a
model describing its behavior. Ideally, behavioral models are generated from the form
automatically. This requires combining information about geometry and materials with
knowledge of the physical phenomena occurring in the component. Creating such models
automatically is difficult in the general case, but can be achieved for certain classes or
families of components. For example, the mechanical behavior of the set of rigid bodies
with homogeneous material properties is completely defined by the mass and inertial
parameters, as is shown in Figure 4.5. These rigid bodies are so common in mechatronic
systems, that it makes sense to develop a procedure that computes the inertial
parameters from the density and the geometry of the component, as defined in a CAD
model. As a result, the behavior models of homogeneous rigid bodies can be derived
automatically for any material and arbitrary geometry.
65
Besides rigid bodies, we can automatically generate behavioral models for parametric
CAD models. In a parametric CAD model, the designer establishes relationships between
certain geometric dimensions or parameters. As a result, the form is completely defined
by a limited set of characteristic parameters or features. Behavioral models also contain
parameters, which, in turn, can be related to the CAD parameters. These relations can be
simple, as in the rigid body example, or can be quite complicated, as for a hydraulic pipe.
As is illustrated in Figure 4.5, the flow resistance of the pipe depends on its length,
diameter, and bending radii. Although these dimensions may not be defined explicitly in
the CAD model, they can be extracted through parametric relations captured as
procedures [23, 124].
Finally, one can consider the case in which both geometric and behavioral parameters
are determined through a lookup table. For instance, given the model type of a DC motor,
a lookup table provides all the parameters for a detailed behavioral model. Similarly, a
Mass, Center of Gravity
Inertia Tensor
Component Model
ωωα IIM
xmF
×+==
∑∑ &&
Pipe diameter
Pipe shape
Pipe Model
Flow Resistance =F(L, R1, R2, D, … )
R1
R2
D
L
MicroMo XYZ DC-Motor
Parameters = Lookup(XYZ)
Mass, Center of Gravity
Inertia Tensor
Component Model
ωωα IIM
xmF
×+==
∑∑ &&
Pipe diameter
Pipe shape
Pipe Model
Flow Resistance =F(L, R1, R2, D, … )
R1
R2
D
L R1
R2
DD
L
MicroMo XYZ DC-Motor
Parameters = Lookup(XYZ)
Figure 4.5. The relation between form and behavior parameters.
66
parametric CAD model is instantiated from parameter values in the lookup table. What
makes this example significantly different from the previous example is that there may not
be any direct relation between the geometric parameters and the behavioral parameters.
The geometry may simply be a high-level abstraction of the DC-motor, capturing only the
external geometry through which the motor can interact with other components. These
simplified geometric representations of the form no longer contain any relevant information
from which an internal behavioral model can be extracted.
This idea of encapsulation of form and behavior can be extended by allowing a
component object to contain design rules or expert knowledge that allow it to adapt its
form to meet the design specifications. Such intelligent components are introduced in
[138]. Multiple intelligent components can be organized into libraries. By searching
through the components in these libraries, the designer can locate the appropriate
component (or system of components) for a particular desired function. Such an intelligent
synthesis assistant may search the component library based on queries regarding the
component’s behavior and form.
4.4 Illustrative Example
To illustrate the concepts developed in the previous sections, we will elaborate the
train system example from Chapter 3. Given that the focus of this work is on ports and
interactions, we will focus on the interaction between the train and its track.
In a real-world train-track interaction, there may be hundreds of physical and
informational interactions between the train and the track, such as mechanical interactions
67
between the train and the track, electrical power flows, command signals, and sensor
signals, as shown in Figure 4.6.
4.4.1 Configuration
Our framework supports the configuration of components in the virtual prototype by
instantiating and connecting them. So the first step is to select the components that will
constitute the virtual prototype. At the highest level of abstraction, we model the train-track
interaction with the train component interacting with the track component. We select a
train and a track component. In early design, no CAD models are available and the
designer provides the parameter values for mass, moment of inertia, etc. The designer
connects the train component to the track component via the “train-track interaction”
aggregate port.
Once the configuration is complete and all component interfaces are connected, the
designer proceeds to the modeling layer to select behavioral models.
4.4.2 Refinement: Configuration
Further along the design process, the designer decides that further refinement is
necessary in the train component. This requires elaborating the train component in the
configuration layer and selecting refined models in the modeling layer. Attributes are
added to the train component attribute tree. Refined behavioral models are selected by
refining the model search criteria with more attribute-value pairs. For example, a new
motor component could be selected by choosing to use a DC motor (with appropriate
attributes) instead of a generic electromechanical transducer.
68
A new configuration is developed for the train component. The train is instantiated
with a CAD model as a parameter. The track component is also instantiated with a CAD
model parameter. The train component is now configured as a composition of sub-
components: a DC motor, a drive train, a body component, and a control system
component (Figure 4.6).
4.4.3 Refinement: Modeling
When developing the corresponding behavioral model, models are chosen for each
sub-component in the train component from each behavioral model container, as well as
for the track component.
In this stage of detailed conceptual design, the mechanical model of the body of the
train is still a simple translational Newton-Euler model, but a DC motor model is added to
convert electrical to mechanical energy, and a drive train model increases the torque
output of the motor using a simple gear interaction model.
4.4.4 Discussion
In this example, we have used our attribute-formalism to select and iterate ports and
Train
Train-TrackInteractionDrive Train
ControlSystem
Motor
Train Body
Track
Mechanical Port
DC Electrical Port
Train control Port
Train
Train-TrackInteractionDrive TrainDrive Train
ControlSystem
Motor
Train BodyTrain Body
Track
Mechanical Port
DC Electrical Port
Train control Port Figure 4.6. High-level component configuration for a single car train interacting with a track. Each block
represents a component, and a circle represents a port on the component interface. Lines represent non-causal connections and arrows represent directed connections.
69
interaction models. Attribute-based representations allow us to define ports and models by
their characteristics, rather that by their position in a taxonomy.
In the design iteration, we have used abstraction, both in the configuration and in the
modeling layer. Abstraction serves an important purpose: to reduce the amount of detail
presented to the designer so that he or she can focus on high-level modeling decisions
without dealing with small details.
Separation of the interfaces from the content of models (whether behavior or
configuration) has the added advantage of encouraging standardization and reuse of
these models in later design projects.
4.5 Summary
We presented a framework where designers can create virtual prototypes of
electromechanical systems by configuring components, while simultaneously selecting
and assigning CAD parameters and behavioral (simulation) models.
To generate system-level behavioral models from component configurations, the
behavioral models of the individual components need to be combined with behavioral
models of the interactions between the components. We introduced a mechanism to
extract such interaction models automatically based on the matching between component
ports and an attribute grammar of interaction models. Our framework supports the
designer throughout the design process by providing mechanisms for abstraction,
automatic model selection and model reuse.
70
5 Component Interactions5
5.1 Introduction
The mathematical modeling of virtual prototypes has evolved over time. Many early
simulation languages were based on the Continuous System Simulation Language
(CSSL) [137]. Models were written as sequential procedures, which implied a fixed
mathematical causality. They were implemented as monolithic pieces of software with no
separation between model and solver. Subsequently, object-oriented principles have been
applied to systems modeling [8, 30, 54], with the result that models are easier to create,
reuse and share. Causality assignment is performed automatically, and the solver is
independent of the model. However, the product design methodology is still not closely
coupled with the modeling methodology.
5 This chapter is based on the following published papers:
• Sinha, R.; Paredis, C.J.J.; and Khosla, P.K., “Interaction Modeling in Configuration Design”, Proceedings of the ASME Design Engineering Technical Conferences, September 9-12, 2001, Pittsburgh, Pennsylvania, USA.
• Sinha, R.; Paredis, C.J.J.; and Khosla, P.K., "Kinematics Support for Design and Simulation of Mechatronic Systems”, Proceedings of the 4th IFIP Workshop on Knowledge-Intensive CAD, May 22-24, 2000, Parma, Italy.
Connector Conspiracy, n: [probably came into prominence with the appearance of the KL-10, none of whose connectors match anything else]
The tendency of manufacturers (or, by extension, programmers or purveyors of anything) to come up with new products which don't fit together
with the old stuff, thereby making you buy either all new stuff or expensive interface devices. The New Hackers Dictionary
The ability to relate and to connect, sometimes in odd and yet striking
fashion, lies at the very heart of any creative use of the mind, no matter in what field or discipline. George J. Seidel
71
As described in the previous chapter, we further the evolution towards a seamless
integration of design and simulation by introducing the idea of a component object. They
contain their configuration information as well as behavioral models and design data. They
are connected to other component objects via ports. In our framework, the virtual
prototype is created once all the component objects are interconnected.
Connecting component objects via their ports is not sufficient to create a complete
system-level model [133]. The behavioral models of each component object must also be
connected to each other. However, as we will show in subsequent sections, merely
making a connection between the modeling ports can result in an incorrect model in many
cases.
We introduce the idea of component interaction models that connect the behavioral
models of two interconnected component objects. For a composition operation over
component objects to be successful in generating a system-level virtual prototype,
component interaction models are required. Interaction models capture the physical
dynamics at the interfaces between components. This chapter presents a framework that
supports the following aspects of interaction modeling:
Model organization. Several models can represent a particular physical phenomenon.
These models should be classified and organized so that the designer is not inundated
with choices. We define an interaction model container to organize interaction models.
Reuse through standardized representation. All interactions between the
component and its environment occur through the component’s interface. Therefore, a
library of interaction models can be indexed by their interfaces. Candidate interaction
models can be selected by searching the library for models with interfaces compatible with
72
the interfaces of the connected components. We standardize interfaces by utilizing two
concepts: ports and instantiation parameters. A port represents an intended interaction
between a component and its environment. An instantiation parameter represents
information that must be provided to define a component unambiguously. Interfaces are
also represented using attributes.
Capturing component interaction dynamics. When two components are connected
via their interfaces, the connection implies that there is an intended physical interaction
between the two components. This interaction must be captured in a behavioral model.
The interaction can be as simple as applying Kirchhoff’s Laws to an electrical connection.
Or it can be more complex such as applying a kinematic joint model to a mechanical
connection.
In this chapter, the focus is on characterizing, modeling and organizing the interactions
between components. With this objective in mind, we model interactions as containers for
a family of interfaces. We describe the port-based representation of interfaces and how
the interface mediates interactions between components. We apply our insights to
generating a system-level virtual prototype for the train example introduced in previous
chapters.
5.2 Behavioral models For interactions
Component interactions are modeled as behavioral models that capture the
mathematical description of the physical interaction. As for the behavioral models
associated with component objects, we consider these models to consist of either
differential-algebraic equations (DAEs) for continuous time phenomena, or discrete event
73
systems specifications (DEVS) [165], or composed out of other behavioral models through
the port-based modeling paradigm [42].
Behavioral models for interactions are different from those for component objects.
They are not associated with geometry, but they may be instantiated with parameters that
are computed from the geometry of the connected component objects.
5.3 Interaction Models and Containers
When a designer composes a system from components, he connects the configuration
ports of components. By doing this, the designer explicitly indicates that there is an
intended interaction between the connected components. The connections represent
physical or information-exchange phenomena that occur at the component interfaces. In
Figure 5.1(a), the resistor, capacitor and AC source have 2 pins each that are connected
at A, B and C to form the circuit. There is a one-to-one correspondence between the circuit
connections and the connections between the behavioral models. The correspondence is
modeled using Kirchhoff’s current and voltage network laws, resulting in a correct system-
level model.
In the mechanical and other domains, a connection between components cannot be
correctly modeled by merely connecting the corresponding behavioral models. In Figure
5.1(b), the shaft is connected to the bearing. Applying Kirchhoff’s network laws at the
connection point A results in the positions Pr
being equal and the generalized forces Fr
summing to zero. This implies a rigid joint between the shaft and the bearing, which is
incorrect.
74
Introducing an interaction model at A that captures the dynamics at the interface
between the shaft and bearing solves this problem. Depending on the type of
configuration ports that are connected, candidate interaction models are chosen
automatically.
There are a finite number of possible interaction model interfaces that can represent
the connection between the configuration ports. In general, if there are m and n candidate
behavioral ports for configuration ports 1 and 2 respectively, then the space of behavioral
model interfaces representing the component interaction has an upper bound of m n× .
The interaction model then becomes a container for this set [131]. For example, consider
the two gear components in Figure 5.2. When the designer makes a connection between
the two gear ports in the configuration level, a container interaction model is instantiated in
the modeling layer. The container holds all the possible behavioral models that can be
used to represent this interaction. Searching a library of interaction models populates the
(a)
(b)
Figure 5.1. Composition of behavioral models in the electrical and mechanical domains. In (a) the composition occurs
via the application of Kirchoff’s Laws. However, in (b), applying Kirchoff’s Laws results in an incorrect rigid joint.
Resistor Capacitor
AC Source
A
B C
R C
VAC
A
CB
Kirchoff LawsAt A, B and C
1 2
1
0
n
N
k k
V V V
I=
= = =
=∑K
“Correct Model”
Resistor Capacitor
AC Source
A
B C
Resistor Capacitor
AC Source
A
B C
R C
VAC
A
CB
R C
VAC
A
CB
Kirchoff LawsAt A, B and C
1 2
1
0
n
N
k k
V V V
I=
= = =
=∑K
“Correct Model”
Kirchoff LawsAt A, B and C
1 2
1
0
n
N
k k
V V V
I=
= = =
=∑K
“Correct Model”
ShaftBearing
Shaft BearingA
Kirchhoff Laws At A1 2
1 2 0
P P
F F
=+ =
r rr r
“Rigid Joint –Incorrect Model”
A
ShaftBearing
ShaftBearing
Shaft BearingA
Kirchhoff Laws At A1 2
1 2 0
P P
F F
=+ =
r rr r
“Rigid Joint –Incorrect Model”
A
75
container. In this example, the possible models are two gear interaction models. The
parameters of the interaction can be inferred by geometric reasoning on the CAD data in
each component [128].
Potentially, a very large number of behavioral models can be present in the interaction
model container, and two or more of these models may be closely related. In Figure 5.2,
both the gear interaction models are closely related in that they have the same interface,
but slightly different dynamics. In the previous chapter, to organize and maintain the space
of all possible interaction models, and to support evolution of the design, we presented an
attribute grammar for ports.
The choice of a particular model from the container depends on the nature of the
simulation experiment that is being performed. In Figure 5.2, there are two gear interaction
models in the gear interaction container. One is a simple kinematic gear interaction model
with two 3D mechanical ports. Another is a complex gear interaction model with
kinematics and frictional dynamics. The first model may be used in preliminary design,
when a high-level simulation is needed. The second model would be used later in the
design process, when a detailed simulation is performed. Both models are valid choices,
and are presented as possible alternatives in the interaction model container for this
Gear Radii Gear InteractionR2
R1
N1N2
α2
α1
R2
R1
N1N2
α2
α1 Number of teeth,Pressure angle etc.
Gear Interaction 2
N=R2/R1F1=f(N,N1,N2,α1, α2)
Gear Interaction 2
N=R2/R1F1=f(N,N1,N2,α1, α2)
Gear Interaction 1
N=R2/R1
Gear Interaction 1
N=R2/R1
Mechanical Modeling PortGear Configuration Port Figure 5.2. Interaction model as a container for a set of reconfigurable models. In this example, the container lists
two possible behavioral models for this interaction.
76
connection.
The ports on the models in the container are related via our port formalism and our port
attribute grammar. A port on the one interaction model can be a supertype of a port on
another model. This capability allows the designer to encapsulate ports within ports, and
create multiple levels of abstraction for the interaction models in the design. At each level,
he can work with ports and interaction models whose information richness is sufficient for
the current abstraction level. This allows the designer to create and simulate virtual
prototypes for complex, hierarchical devices by selecting and connecting components via
their interfaces.
5.4 Derivation of the Interaction Model from Component Objects
In addition to the behavioral models of component objects, systems include models
describing the interactions between component objects. For each pair of interacting
component objects, there is an interaction model that relates the port variables of the two
objects to each other.
PhysicalObject A
PhysicalObject B
Interaction Model
Interaction Model
Mechanical Domain(complex interaction)Mechanical Domain(complex interaction)
Joint Model, Gear Model, Friction.
Electrical Domain(default interaction)Electrical Domain(default interaction)
BA acrossacross =0throughi =∑
ComponentA
ComponentB
Node ComponentA
ComponentB
InteractionComponent
PhysicalObject A
PhysicalObject B
Interaction Model
Interaction Model
Mechanical Domain(complex interaction)Mechanical Domain(complex interaction)
Joint Model, Gear Model, Friction.
Electrical Domain(default interaction)Electrical Domain(default interaction)
BA acrossacross =0throughi =∑
BA acrossacross =0throughi =∑
ComponentA
ComponentB
Node ComponentA
ComponentB
InteractionComponent
Figure 5.3. Interactions between system components.
77
Any interaction in any energy domain requires an interaction model. However, for the
electrical domain, the interaction model is usually very simple. An electrical connection
between two components is modeled sufficiently accurately by constraining the voltage at
the two connecting ports to be equal and the current through them to sum to zero.
Because this interaction model is so common, we allow it to be omitted in our modeling
framework, as is shown in Figure 5.3. In the mechanical domain, the equivalent default
model is rarely appropriate. Even when connecting two components rigidly, their
reference frame is usually in a different location so that a model representing the
coordinate transformation is needed [129].
Besides rigid connections, other common mechanical interaction models are the lower
pair kinematic constraints. Algorithms have been developed to predict the instantaneous
degrees of freedom from the CAD models of parts composed of polygonal planar faces
[87]. However, these algorithms handle only parts with planar faces while most
engineering devices have curved parts. When curved parts are approximated as
piecewise planar parts, it is possible to overlook degrees of freedom in the device, due to
erroneous collisions. In the next chapter, we describe the algorithms to obtain lower pair
mechanical interaction models automatically from the geometry of the connected
component objects.
5.5 Illustrative Example
78
To illustrate the concepts developed in this chapter, we elaborate the train system
example introduced in the previous chapter. Given that the focus of this chapter is on
interactions, we will focus on the interaction between the train and its track. We will
demonstrate automatic selection, abstraction and design refinement of interaction models.
5.5.1 Initial Interaction Modeling
In the previous chapter, we selected a train and a track component. The designer
connects the train component to the track component via a “train-track interaction”
aggregate port.
In the modeling layer, a high-level train-track interaction model is automatically
selected and instantiated, based on the nature of the connected ports. This interaction
model is a container for every behavioral model that can be used to describe the
interaction between the train and the track (Figure 5.4).
Train-Track Interaction 2
Wheel Interaction Model
Electrical-positive
Electrical-Negative
Control
rolling w/friction
rolling w/friction
rolling w/friction
rolling w/friction
Train-Track Interaction 2
Wheel Interaction Model
Electrical-positive
Electrical-Negative
Control
rolling w/friction
rolling w/friction
rolling w/friction
rolling w/friction
Train-Track Interaction 1
Translation Model
Train-Track Interaction 1
Translation Model
Figure 5.4. Train-track interaction model container that captures all the candidate interaction models that can model
the connection between the train and the track.
79
The choice of behavioral model depends on the design stage and the requirements of
the simulation. In this stage of early conceptual design, the particular behavioral model
chosen is a simple Newton-Euler mechanical model; the train-track interaction port has
only one sub-port (a 3D mechanical port), and the interaction model only considers
mechanical translation of the train along the track (Figure 5.5).
When modeling is complete, it is possible to simulate the virtual prototype by
translating the behavioral models into Modelica and evaluating them in a commercial
Modelica simulator.
5.5.2 Refinement of the Interaction Model
Using the grammar, the train-track interaction port is refined to three sub-ports that are
connected together on either high-level component. These ports are the control port, the
mechanical port, and the DC electrical port. With the train being modeled in CAD as a
detailed solid object, the train-track interaction model in Figure 5.6 can be automatically
derived from the geometry. The parameter extraction engine examines the current CAD
model for the train and track components, obtains the material properties and wheel
Train-Track Interaction 1
Translation Model
Train-Track Interaction 1
Translation Model
Figure 5.5. The train-track interaction model at the early design stage. The mechanical interaction has been
disaggregated into the individual ports for the four wheels of the train.
80
geometry and uses a look-up table to obtain the friction coefficient for a coulomb friction
model.
This provides all the necessary information to complete the system model and
evaluate it in a Modelica solver.
5.5.3 Discussion
To generate system-level behavioral models from component configurations, the
behavioral models of the individual components need to be combined with behavioral
models of the interactions between the components. We introduced a mechanism to
create an interaction model container automatically based on the matching between
component ports. Our framework supports the designer throughout the design process by
providing mechanisms for abstraction, automatic model selection and model reuse.
Our framework supports automatic interaction model selection and instantiation. The
automation allows the designer to focus on the more important tasks of configuration and
CAD and behavioral model parameter assignment, while accurately capturing the
Train-Track Interaction 2
Wheel Interaction Model
Electrical-positive
Electrical-Negative
Control
rolling w/friction
rolling w/friction
rolling w/friction
rolling w/friction
Train-Track Interaction 2
Wheel Interaction Model
Electrical-positive
Electrical-Negative
Control
rolling w/friction
rolling w/friction
rolling w/friction
rolling w/friction
Figure 5.6. The train-track interaction model in the detailed design stage. The mechanical interaction has
been refined to a rolling joint with rolling friction.
81
intended interactions between components in the configuration. The automation also
maintains consistency between the CAD parameters and behavioral representations.
5.6 Limitations of Interaction Models
Our interaction modeling framework allows us to model the physical interactions that
occur at component interfaces using port-based composition. Our models are object-
oriented, hierarchical and acausal. In some cases, they can also be derived automatically
from the design data of the connected component objects.
We assume that the interaction phenomena occurs at the component interface, and
that the physical interaction is present for the duration of the simulation. In this section, we
discuss the conditions when these assumptions are violated.
The port-based modeling paradigm imposes constraints on the types of models that
can be defined. In particular, all interactions between component objects are limited to
discrete locations on their interfaces. This works well when the energy exchange can be
accurately modeled as being restricted to the interfaces. Our framework supports this type
of interaction model.
Distributed interactions can also be captured within our framework. Instead of a
discrete location, a surface on the interface is involved in the interaction.
82
Field interactions like the gravity interaction (Figure 5.7) involve every physical
location within one component object interacting with every physical location within the
other component object. In this case, the interface extends to the entire mass of the
component object. When there are only two components interacting in a field interaction,
one way of solving this problem is to incorporate the gravity interaction model directly into
the behavioral model of each component object.
Certain interaction phenomena appear and disappear dynamically during the course
of a simulation. Mechanical collisions or wireless broadcasts are two examples. The port-
based modeling paradigm restricts configurations to be static (i.e. unchanging for the
duration of the experiment), and allows connections between a single pair of component
objects at a time. In the dynamic cases, it is inconvenient to capture every possible
connection between the component objects (i.e. create a maximal configuration), and turn
on and off only those connections that are active at each time step of the simulation.
(a)
(b) Figure 5.7. In (a), the mechanical interaction between the shaft and the bearing is localized their interfaces the outer
curved surface of the shaft and the inner curved surface of the bearing. However, in (b), The gravity interaction between the planet and the satellite is not limited to the surface, and involves the entire mass of both components (image from
NASA MAP Science Team).
ShaftBearing
ShaftBearing
83
It is also important to bear in mind that the space of possible interaction models is
bounded by the set of attributes in the attribute grammar. This implies that physical
phenomena that are not defined via attributes in the grammar will not be available as
possible interaction models in the interaction model container. The set of attributes only
captures the set of interaction phenomena that are of current interest to the designer and
have been modeled by the designer; un-modeled interactions will not be considered. New
phenomena are added by extending the grammar.
Certain phenomena that occur in complex systems cannot be described by the sum of
the interactions of the constituent components. Such phenomena are called emergent
phenomena [35]. Our framework cannot capture such interactions. The formal grammar
approach implies that a higher-level construct such as an emergent interaction must be
expressible in the grammar as an aggregation of lower-level interactions.
84
6 Automatic Extraction of Mechanical
Interaction Models6
6.1 Introduction
Mechanical interaction models are an important class of interaction models that are
instantiated while making mechanical connections between two component objects. When
two component objects are connected mechanically, there is a physical contact between
the CAD features of each component. For example, when a shaft is connected to a
bearing, the outer cylindrical surface CAD feature of the shaft is in contact with the inner
cylindrical surface CAD feature of the bearing. The type and attributes of these CAD
features determines the interaction model. In this chapter, we provide a set of algorithms
that determine the interaction model when the contacting CAD features are surface-
surface contacts.
6 This chapter is based on the following published papers:
• Sinha, R.; Gupta, S.K.; Paredis, C.J.J.; and Khosla, P.K., "Extracting Articulation Models from CAD Models of Parts with Curved Surfaces", ASME Journal of Mechanical Design, 124, in press.
• Sinha, R.; Paredis, C.J.J.; Gupta, S.K.; and Khosla, P.K., "Capturing Articulation in Assemblies from Component Geometry", Proceedings of the ASME Design Engineering Technical Conferences, September 1998, Atlanta, Georgia, USA.
Equations are just the boring part of mathematics. I attempt to see things in terms of geometry Stephen Hawking
Any impatient student of mathematics or science or engineering who is irked
by having algebraic symbolism thrust upon him should try to get along without it for a week Eric Temple Bell
85
In current design practice, when a device that contains parts with curved surfaces is
considered, reasoning about its behavior is usually done by analytical methods that are
difficult to implement [59, 82], or by approximating all the curves as piecewise planar
surfaces [88]. The approximation is usually based on past experience or on heuristics.
However, such approximations may invalidate the analysis by unintentionally constraining
the degrees of freedom in the device. These erroneous results propagate throughout the
design process, influencing the decisions of part and assembly designers, device
analysts, process engineers, and operators.
Another consideration is the reuse of the derived device models. Even in a
collaborative setting, when a part or assembly from a previous design project is reused,
sometimes all that is known a priori is the geometry of the part or assembly. Only the CAD
model of the part or assembly persists across designs. Behavioral models of the part or
assembly are not reused. In addition, feature-based design of complex devices requires
verification of the fact that actual kinematic behavior matches the required behavior. If
component models that capture the geometry as well as the physical behavior of the
device can be created, it should be possible to construct system-level simulation models
merely by configuring the component models [106].
The above discussion indicates a need for three capabilities that will support all
aspects of the design process - creation of the ability to exactly reason with a broad class
of curved surfaces; the ability to obtain kinematic models from assembly geometry; and
the ability to encapsulate kinematic behavior models and CAD models in the
representation of a part or an assembly. Our research supports the first two aspects, and
86
we have implemented these ideas in COINSIDE, our modular simulation-based design
framework [106].
Frameworks for the detection and representation of articulation behavior in
assemblies can be restrictive. In order to generate assembly or disassembly plans for
such assemblies, the designer needs to take articulation information into consideration.
However, current methods of representing articulation are restricted to systems that
require complete specification by the user [1] or are based on feature recognition [112].
The former are open to incorrect input by the user resulting in illegal articulation behavior.
The latter do not account for incomplete geometry and incidental contacts.
Other methods exist to obtain articulation models by reasoning on the geometric
representation of the artifact. Techniques have been developed to predict the
instantaneous degrees of freedom from the CAD models of parts with only polygonal
planar faces [66, 88]. However, when the curved parts that exist in most engineering
devices are approximated as piecewise planar parts, erroneous results are possible.
In this chapter, we present a methodology that generalizes our earlier work on contact
surfaces [128]. Previously, the instantaneous degrees of freedom at each joint were based
on surface mating constraints that were in turn obtained from analyzing body to body
contacts. We imposed non-penetration constraints along the boundary of each contact
surface in the form of algebraic inequalities. One can show that a finite number of non-
penetration conditions are representative of the entire surface in contact. Using linear
programming methods, we computed instantaneous velocities and accelerations for each
pair of bodies. In this article, we obtain a set of properties that must be satisfied by a
general contact surface in order to preserve the linearity of the model. We describe a
87
method by which the space of allowable motions in the assembly can be described
concisely. We then describe a heuristic that can find feasible joints from the space of
allowable motions.
Such a methodology can provide useful feedback to the designer. He or she can
determine which components are free to move in the assembly. The procedure can be
completely automated, so that there are no errors induced by user interaction. This
eliminates the possibility of input errors. In addition, since the method is algebraic and
uses linear programming, it is relatively fast and is valid for all possible surface contacts,
unlike rule-based systems that operate on a feature level. This method will also account
for contact surfaces with incomplete geometry (such as portions of planes, cylinders, or
spheres).
Our method is subject to the following restrictions. Since our algorithms extract only
lower-pair mechanical interaction models, the CAD models used in the analysis are
assumed to model surface contacts at the joints. The joint contacts induce the
instantaneous degrees of freedom. Since the algorithms detect the instantaneous degrees
of freedom, they are applicable for a single configuration of a mechanism, and cannot be
used to predict all possible configurations of the mechanism.
6.2 Early Work on Contact Mechanics
Previous work on planar contact mechanics and screw theory prepared the foundation
for this work. Ohwovoriole and Roth [101] showed that unidirectional constraints can be
modeled as screws. Hirai and Asada [66] described the allowable motions of a part using
polyhedral convex cones to represent the space of movement. Mattikalli and Khosla [86]
88
described a method to obtain degrees of freedom from component mating constraints,
wherein they use a unit sphere to represent the space of all available degrees of freedom.
Some issues have not yet been addressed satisfactorily in these frameworks. Current
shortcomings in articulation research include:
1. Only bodies described (or approximated) by planar surfaces are considered.
2. Current techniques are local; global interaction (propagation of constraints beyond the
point where they are induced) is not satisfactory.
3. Current simulation techniques do not detect incorrect/incomplete inputs; there is no
verification for correctness of the articulation representation and for the compound
effect of geometric interactions and physics-based interactions.
A part in an assembly is in physical contact with one or more other parts. The nature
of these contacts can provide useful information about the types of the degrees of
freedom at these contact points. Some of these contacts induce surface mating
constraints, leading to the formation of a joint. Other contacts are incidental, in that they
may bound the values of the degrees of freedom of the joint [112, 113]. Reasoning about
these constraints provides the designer with valuable insight into the instantaneous
degrees of freedom of the assembly.
Other researchers [86, 88] have worked with polygonal bodies and polygonal surfaces
of contact. They approximate curved planar boundaries using straight lines, and use linear
programming techniques to solve the contact problem.
When a pair of parts are in contact with each other, it implies that there is no inter-
penetration between the parts at the contact surfaces. Penetration of one part into the
other requires that the relative velocity at one of the points of contact between the parts
89
have a component that is directed opposite to the surface normal at that point. This non-
penetration condition at a point can be written as [88]:
0)( ≥•×+ nrvrrrr ω (6.1)
where vr is the relative translational velocity between two parts, ωr is the relative angular
velocity between two parts, rr is the position of the point and n
r is the normal at a point of
contact on the surface of contact. This equation is linear in vr and ωr. We define the
generalized velocity vector as [ vr ωr].
In Figure 6.1, we show the operation of the non-penetration condition at a point of
contact between two planar surfaces 1 and 2, that are part of body 1 and body 2,
respectively. Point P1 is on surface 1, and is in contact with point P2 on surface 2. nr is the
surface normal at P1, vr and ωr are the relative translational and rotational velocities of the
body pair. rr is the position vector of the contact point P1 (or P2).
Figure 6.2 shows the non-penetration condition along a line segment from P1 to Q1.
For non-penetration at every point on this line segment, it is sufficient that Equation (2.1)
be satisfied at P1 and Q1.
nr1,2Pv rω+ ×r r r
O1,2Prr
1P
2P
1
2
Figure 6.1. Non-penetration condition at a point. Planes 1 and 2 are coplanar but are shown as separated for clarity.
90
To prevent the penetration of one part into the other, Equation (2.1) must be satisfied
at every point on the surface of contact and on the boundary of the surface of contact.
Such a method of expressing planar contact between two bodies has been used before.
For example, Mattikalli et al. [88] use non-penetration conditions to determine the
impending motion direction of polyhedral rigid bodies in contact.
We define a primitive contact patch to be a contact surface that is part of a single type
of surface. A compound contact patch is an aggregation of two or more primitive patches.
A closed planar patch is bounded by a finite set of curves; these curves may be straight
line segments (Figure 6.3) or curved line segments. Any point in the interior of the patch
nr1,2Pv rω+ ×r r r
O
2
1P
1
1Q
2P 2Q
rr
Figure 6.2. Non-penetration condition along a line. r
r is the position vector of an arbitrary point along the contact line
between P1 and Q1. Planes 1 and 2 are coplanar but are shown as separated for clarity.
nr1,2Pv rω+ ×r r r
O
2
1P
1
1Qrr 1R
2P 2Q
2R
Figure 6.3. Non-penetration condition in a polygonal surface. r
r is the position vector of an arbitrary point within the
polygon bounded by P1, Q1 and R1. Planes 1 and 2 are coplanar but are shown as separated for clarity.
91
can be expressed as a linear combination of points at the vertices of the boundary of the
convex hull of the patch. Therefore, the non-penetration condition at any point in the
interior can be expressed as a linear combination of the non-penetration conditions at the
vertices of the convex hull. As long as the convex hull has a finite number of vertices,
there will be a finite number of non-penetration conditions, all of which are linear in vr and
ωr.
When extending to curved surface contacts, it is desirable to preserve the linearity of
the formulation for reasons of computational efficiency; linearity allows for easier search
and boundary enumeration.
6.3 Extending Contact Mechanics to Curved Surfaces
We extend the results obtained for planar surface contacts by showing that similar
results can also be obtained for spherical and cylindrical surfaces defined by edges that
are great arcs (for spherical surfaces) or straight lines and circular arcs (for cylindrical
surfaces) [128].
Spherical surfaces that share a common center always result in unconstrained
rotations when in contact. As before, the non-penetration conditions must be written at the
vertices of the convex hull for the given spherical contact surface. However, since the cost
of computing the convex hull is high, we chose to generate the non-penetration condition
at the vertices of the spherical patch. This will not influence the final result.
The non-penetration conditions at two points on a sphere are written (in a fashion
similar to Equation (2.1) as:
92
( )( )( )( )
1 1
2 2
0
0
v p Rn n
v p Rn n
ω
ω
+ × + • ≥
+ × + • ≥
r r r r rr r r r r
(6.2)
Using techniques similar to those used for planar patches, i.e. multiplying the first
inequality by 1x and the second by 2x , and then adding, we get:
( ) ( )1 1 2 2 0v p x n x nω+ × • + ≥r r r r r (6.3)
where the left hand side term is an expression of nr as a linear combination of 1nr and
2nr for 0 1 2 ix i> ∀ = K . The n nω• ×r r r term is always 0 for all nr, and drops out of the
expression. Therefore, inter-penetration does not occur at any point within the spherical
patch.
Boundary segments of the spherical patch must be discretized into a finite number of
great arcs so that non-penetration conditions can be imposed at each end-point of the
arcs. When the angle subtended by a great arc at the center is greater than π, then a third
point should be picked in between the end points such that the angle between the first and
third points as well as the angle between the second and third points are both less than π.
This will ensure that the normals at the first and third points span the circular arc between
the first and third points. Similarly, the normals at the second and third points span the
circular arc between the second and third points. The non-penetration condition for the
third point should be added to the set of non-penetration conditions for this patch.
Cylindrical surface contacts, by virtue of the fact that the contact surface is curved, do
not have a normal vector that is constant over the entire patch. Thus, we define a normal
with the following property:
93
0n o• =rr (6.4)
with the origin of the cylinder at pr and or along the axis of the cylinder of which the
patch is a part. Now, the non-penetration conditions at two points 1 and 2 on the patch
becomes:
( )( )( )( )
1 1 1
2 2 2
0
0
v p z o Rn n
v p z o Rn n
ω
ω
+ × + + • ≥
+ × + + • ≥
r r r r r rr r r r r r
(6.5)
where pr is the origin of the cylinder, iz is the distance from the origin to the point in
question, along or and R is the radius of the cylinder of which the patch is a part.
Equation (6.5) should hold at every point on the cylindrical patch for the non-
penetration condition to be valid. Multiplying each inequality by 1x , 2x and so on, and then
adding results in:
( ) ( ) ( ) ( )1 1 2 2 1 1 1 2 2 2 0v p x n x n x z n x z n oω ω+ × • + + + • × ≥r r r r r r r r r (6.6)
During the consideration of each patch boundary segment, it is necessary to show
that there exist 1 1 2 2n x n x n= +r r r and 1 1 1 2 2 2zn x z n x z n= +r r r with 0n o• =rr for the segment.
6.3.1 Considering Boundary Points Constant in z
To show that for a boundary segment with constant z, the θ coordinate of a point on
the boundary can be expressed as a linear combination of the θ coordinates of the end
points, we set 1 2z z z= = in Equation (6.6) to get:
94
1 1 2 2
1 1 2 2
x n x nn
x n x n+=+
r rr r r (6.7)
Points that subtend an angle at the axis greater than π are resolved by considering an
additional point at the middle of the circular contact arc between these two points. Then
the angle between each of the original points and the newly added point will be less than
π. The normal vectors at two points with the same z and different θ span the possible
normals between the two points. Therefore the non-penetration condition at any point on a
boundary segment with constant z is satisfied if non-penetration is satisfied at the end
points of the segment.
6.3.2 Considering Boundary Points Constant in θ
To show that for a boundary segment with constant θ, the z coordinate of a point on
the boundary can be expressed as a linear combination of the z coordinates of the end
points, we set 1 2n n n= =r r r in Equation (6.6) to get:
1 1 2 2
1 2 1z x z x zx x
= ++ =
(6.8)
The normal vectors at two points with the same θ and different z have normals that
are equal. Thus, these two points are very similar to the end-points of a straight line in a
plane. Therefore the non-penetration condition at any point on a boundary segment with
constant θ is satisfied if non-penetration is satisfied at the end points of the segment.
6.3.3 Considering Boundary Points Varying in z and θ.
For situations when the points on the boundary of the patch vary both in z and in θ, it
is impossible to find an 1 1 2 2n x n x n= +r r r such that 1 1 1 2 2 2zn x z n x z n= +r r r. So, we discretize the
95
boundary using segments of constant z and constant θ. This ensures that along each
discretized segment, the linear relationship between the end points holds.
Therefore to summarize, for cylindrical surfaces, non-penetration at every point in a
contact patch with boundary segments that are exclusively straight line (constant-z) and
circular (constant-θ) segments can be represented entirely by non-penetration at the
vertices of these segments.
6.4 Generalized Contact Mechanics
In the previous section, we indicated that the linear properties of planar contact
mechanics models can be preserved when curved surface contacts are modeled. This is
possible if the contact surface boundary can be described by a finite number of segments
such that satisfying the non-penetration condition the end points of the segments is
necessary and sufficient to satisfy the condition at any point on the curved surface. This
section defines and proves the necessary conditions.
The nature of the physical contact between a pair of parts in an assembly provides
useful information about the types of the degrees of freedom. Some of these contacts
induce surface mating constraints, leading to the formation of a joint. Other contacts are
incidental, in that they bound the values of the degrees of freedom of the joint. A contact
implies that non-penetration between the parts at every point on the contact surface. Non-
penetration conditions can be written as inequalities that are linear in the instantaneous
velocity, which when taken together, describe a linear subspace.
The following Proposition will be used to establish a theoretical basis for the linear
treatment of curved surfaces in assembly modeling [132].
96
Proposition 1. Given:
1. A continuous curve 3( ) : [0,1]C λ λ∈ → ℜ .
2. 31 2 1 2(0) and (1) ; ,C P C P P P= = ∈ ℜ
3. C lies on a parametrizable, differentiable contact surface S formed between two bodies
A and B.
Then non-penetration (by Equation (2.1)) at P1 and P2 implies non-penetration at any point
on C, if and only if:
1. C is a circular arc, possibly with infinite radius (limiting case of a straight line)
2. The unit normal to C at any point along C is equal to the unit normal to S at that point.
Proof. We prove Proposition 1 by showing that given Equation (2.1) written at P1 and P2,
Equation (2.1) holds along a set of points between P1 and P2.
Equation (2.1) written at P1 is:
0)( 11 ≥•×+ nrvrrrr ω (6.9)
and at P2 is:
0)( 22 ≥•×+ nrvrrrr ω (6.10)
where vr is the relative translational velocity between the bodies A and B, ωr is the relative
angular velocity between the two bodies, 1rr and 2r
r are the position vectors of P1 and P2,
97
respectively. 1nr and 2n
r are the normals to S at P1 and P2 respectively. Forming a linear
combination of Equation (6.9) and Equation (6.10), we get:
[ ]1,0 with 0))(1()( 2211 ∈≥•×+−+•×+ λωλωλ nrvnrvrrrrrrrr (6.11)
Rearranging terms in Equation (6.11), we get:
0)1())1(( 221121 ≥ו−+ו+•−+ rnrnvnnrrrrrrrrr ωλωλλλ (6.12)
For Equation (6.12) to be true and of the form of Equation (2.1), the following would have
to be true ωrr,v∀ :
21 )1( nnnrrr λλ −+= (6.13)
and
rnrnrnrrrrrrrrr ו=ו−+ו ωωλωλ 2211 )1( (6.14)
Equation (6.13) is an expression that indicates that nr only spans the normals from 1n
r to
2nr. By substituting Equation (6.13) in Equation (6.14) and using the vector identity
A B C B C A• × = • ×r r r rr r
to rearrange terms, we get:
( ) ( ) 1 1 2 2 1 2(1 ) (1 )r n r n r n nω λ λ ω λ λ• × + × − = • × + −r r r r r r r r r (6.15)
Equation (6.15) is true if 0ω =rr
(the trivial case for no rotational motion). For Equation (8)
to be also true for 0ω ≠rr
, it is sufficient to show that:
98
rnnrnrnrrrrrrr ×−+=×−+× 212211 )1()1( λλλλ (6.16)
Equation (6.16) is an expression for the generatrix or trace [61] rr of C that generates a
locus of points where Equation (2.1) is satisfied, given that it is satisfied at P1 and P2.
Taking the dot product of Equation (6.16) with 1nr and 2n
r and rearranging terms, we get:
( ) ( ) 0
0
212
211
=ו−=ו−
nnrrnnrr rrrrrrrr
(6.17)
Thus, for non-planar contacts, rr lies in the plane containing both P1 and P2 and normal to
the vector 21 nnrr× . For planar contacts (the trivial case), 1 2n n n= =r r r
and Equation (6.12)
reduces to:
( )( )1 2(1 ) 0v r r nω λ λ+ × + − • ≥r r r r r (6.18)
Which is of the same form as Equation (2.1). Properties 1 and 2 are then satisfied, and
Proposition 1 is proved.
For the nontrivial case, assuming that 21 nnrr× is a non-zero vector, we can then
parameterize rr as (see Figure 6.4):
99
21 )1( and nnnnn
orrrrr
rrr ββα −+=+= (6.19)
Where or
is an arbitrary origin. Using Equation (6.19) to substitute for rr, 1rr and 2r
r in
Equation (6.16) and expanding, we get:
[ ] 021rrr
=−× βλαn
nn
(6.20)
From Equation (6.20), it follows that since 21 nnrr× cannot be zero (as per our assumption),
λ is equal to β. In all of the subsequent analysis, we will use β, with the understanding that
the parameterizations by λ and β are equivalent.
The curve described in Equation (6.19) must lie on the specified surface S. This is
equivalent to saying that the tangent vector to the curve at every point on the curve must
be perpendicular to the normal to the surface and the normal vector to the curve must be
parallel to the normal vector to the surface. We enforce this by the following constraint on
C:
O P2
P1
1nr
2nrnrrr
O P2
P1
1nr
2nrnrrr
Figure 6.4. Plane containing r
r also contains the normal vectors to r
r.
100
0)( =• sndsrd rr
(6.21)
where s is the arc length, and )(snr is the normal vector field. Substituting from Equation
(6.19):
dsd
n
dndn
nn
dndn
nn
dsd
dsrd βββ
αα
•−
+
=
2
1
r
rrrrrr
rrr
(6.22)
or, upon simplification and substitution of Equation (6.22) in Equation (6.21):
0)( ==• ndsd
sndsrd rrr α
(6.23)
which implies that:
( ) constant=sα (6.24)
With Equation (6.24), Equation (6.19) reduces to that of a circular arc in the plane. The
unit normal vector to any point on this arc is equal to the unit normal vector to the surface
S at that point. This established properties 1 and 2.
To prove the converse, i.e. given a circular arc lying on the surface S with the unit normal
vector field to the arc equal to the unit normal vector field of the surface, we write
Equations (6.9) and (6.10) for a circular arc. Thus Equation (6.9) becomes:
0))(( 11 ≥•+×+ nnRovrrrrr ω (6.25)
and Equation (6.10) becomes:
101
0))(( 22 ≥•+×+ nnRovrrrrr ω (6.26)
where R is the radius of the circular arc. Expanding Equations (6.25) and (6.26) and
forming a linear combination:
0))1(()( 21 ≥−+•×+ nnovrrrrr λλω (6.27)
which is of the same form as Equation (2.1). Therefore, non-penetration at the points P1
and P2 implies non-penetration all along C. Note that this is similar to the proof of non-
penetration along a circular arc on a right circular cylinder, presented in Sinha et al. [128].
This completes the proof of Proposition 1.
Lemma 1.1. The curve C exists on surface S when:
1. ( ) ( ) 02121 =ו− nnrrrrrr
2. The intersection of S with the above plane is a circular arc.
Proof. The above two conditions follow from Proposition 1. Curve C lies in a plane
containing the points P1 and P2, as defined in Equation (6.17). C is also a circular arc on
S, as shown in Equation (6.24).
Corollary 1.1. The straight line 21 )1(]1,0[:)( rrlrr λλλλ −+→∈ on a plane surface S
satisfies Proposition 1.
102
Corollary 1.2. The great arc on a spherical surface S subtending an angle less than π
satisfies Proposition 1.
Corollary 1.3. The straight vertical line parallel to the axis and the circular arc subtending
an angle less than π on a right circular cylindrical surface S satisfies Proposition 1.
Proof. Corollaries 1.1 through 1.3 are discussed and proved individually in Sinha et al.
[128]. Here, we show that they emerge as special cases of Proposition 1. As per the
Proposition, the only possible segment on a planar surface (Corollary 1.1), with 1nr equal
to 2nr, is the circular arc with infinite radius, i.e. the straight line joining the points P1 and
P2. The great arc on a spherical surface also satisfies Proposition 1. The possible
segments on a right circular cylindrical surface are the vertical straight line and the circular
arc. The subtended angle is required to be less than π to prevent 1nr being parallel to 2n
r.
Corollary 1.4. The straight vertical line starting at the apex of a right conical surface S
satisfies Proposition 1.
Proof. Upon examination of a right circular conical surface, we see the straight line (or
meridian lines) of the cone has its unit normal vector equal to the unit normal vector of the
surface of the cone. Therefore, Proposition 1 is satisfied. Note that circular arcs can be
present on the cone, but do not satisfy Proposition 1 because the unit normals along the
arc do not point in the same direction as the normal vectors of the cone.
103
6.5 Articulation in Assemblies
This section describes how the space of allowed motion is computed from the non-
penetration conditions, and how the model of the space can be queried to provide
designer feedback. When an unconstrained degree of freedom exists, the space of
allowed instantaneous motion generated from the non-penetration conditions will be non-
empty. The space can be analyzed to provide feedback to the designer.
6.5.1 Solving the Set of Non-Penetration Conditions for Instantaneous Articulation
Each primitive patch induces a non-penetration condition at each of its (finite) vertices.
Since penetration must not occur at any point at any time, the inequalities for all the non-
penetration conditions for the all the patches of a pair of bodies considered simultaneously
form the linear program:
patches all in verticesofnumer Total1 0)( Krrrr =≥×+• irvn ii ω (6.28)
where vr and ωr are the relative velocities between the two parts, in
r is the normal at each
vertex and irr
is the position of each vertex.
Since at any time, all the non-penetration conditions for all the parts must be satisfied,
it is possible to solve all the inequalities for all the vertices of all the parts in the same
linear program. This will result in a solution that is globally valid. Using a single linear
program, it is possible to obtain all the instantaneous degrees of freedom for the
assembly. If we write the non-penetration condition for a patch concisely as:
104
0rrr
rr≥
−−
BA
BApatch
vvωω
J (6.29)
where Jpatch is the non-penetration inequality coefficient matrix for that particular patch.
Then the non-penetration conditions for all the patches in a body-body contact pair formed
between bodies A and B can be written as:
02
1 rrrrr
Mrrrr
≥
−−
=
−−
BA
BA
patch
patch
patch
BA
BAAB
vvvv
p
ωωωωJ
JJ
J
(6.30)
where p is the number of patches in which this body-body pair participates. Writing
Equation (6.30) for all the body-body contact pairs in an assembly, we get:
0r
Mrrrr
MOMMMLL
Mrrrr
≥
−
−=
B
B
A
A
BCBC
ABAB
B
B
A
A
assembly v
v
v
v
ω
ω
ω
ω0JJ000JJ
J
(6.31)
where Jassembly is a complete representation of the assembly with instantaneous
articulation. Solving this global simplex provides all the translational and angular velocities
for all the body-body pairs simultaneously.
The simplex is (6N-6)-dimensional (3 variables for translational velocity and 3
variables for angular velocity for each of N-1 ungrounded bodies in the assembly). Since
the origin is a vertex of this high-dimensional space, this structure is also called a
Polyhedral Convex Cone. Such structures have been studied extensively by Goldman and
105
Tucker [60] and others. Hirai and Asada [66] used cones to describe the possible contact-
preserving and contact-breaking motions between two polyhedral bodies.
6.5.2 A CAD Implementation for Instantaneous Articulation
Having established a theoretical framework for treating curved surface contacts in the
previous sections, we now describe the system that extracts non-penetration conditions
from the CAD models of parts in an assembly. A contact graph structure G can be used to
represent the assembly (Figure 6.5). In the contact graph, parts are represented as nodes,
and contacts between parts are represented as edges between the corresponding nodes.
Edges between nodes are automatically derived by performing intersections between the
corresponding parts.
( ) Band A between onintersecti ofResult ;parts; ofSet ,:,, =≠∈= IBABAIBAG (6.32)
where G is the contact graph that contains a finite number of 3-tuples. Each 3-tuple
contains two parts and an intersection set.
The intersection information in each edge is examined for features that could indicate
the presence of surface mating constraints. Each element of I can be thought of as a
constraint patch on the mating surface between A and B. For a particular element, all
Base Arm
SliderRotor
Figure 6.5. Contact graph for a 4-part assembly. Nodes represent the four parts. Edges represent the contacts. The contact surface that forms the intersection set is shown in each edge
106
boundary segments that do not satisfy Proposition 1 are discretized into primitive
segments (straight lines on planes, circular arcs and straight lines on a cylinder for
constant z and constant θ respectively, and great arcs on a sphere), each of which satisfy
Proposition 1. The set I can be partitioned as:
444 3444 21 UKUUUn
nSSSSI finite
321= (6.33)
where S1 through Sn are a finite number of primitive surfaces (or patches). On each S,
there exists a finite set of boundary segments Ω :
44 344 21 UKUU
m
m
finite
21ˆ s.t. S of segmentsboundary ofSet :
ααασσσσ
=≈∈=Ω
(6.34)
where σ is either a primitive segment, or can be approximated as σ which is a union of a
finite number of primitive segments α. Thus, the intersection set I is composed of a finite
number of primitive boundary segments.
The non-penetration condition for each end-point or vertex of each primitive boundary
segment α is written as a constraint in the linear program. The linear space can now be
described (or enumerated) using standard boundary enumeration techniques. Note that
this technique will work only for those surfaces that satisfy Proposition 1. On other
surfaces such as splines, non-penetration conditions would have to be written for every
point on the surface.
Finding one solution to the simplex is easy; finding all solutions is a more difficult
proposition. However, useful information can still be obtained by projecting the simplex on
either the vr
, or the ωr space. Such linear programming methods have previously been
used by Mattikalli et al. [88] to obtain solutions to the stability problem for assemblies.
107
Solutions are returned in the form of allowable instantaneous translational and
angular velocities. Translational velocities of zero indicate that translation is constrained
for that body-body pair. Angular velocities of zero indicate that rotation is constrained for
that body-body pair.
6.5.3 Giving Feedback to the Designer
In order to completely describe all the possible relative motions of the assembly, it is
necessary to completely describe the boundary of the polyhedral convex cone in 6N-6-
dimensional space.
Useful feedback can be provided to the designer in the form of questions such as:
“What degrees of freedom exist when the rotations of a particular part are constrained?”
This question can be answered by adding 0rr=ω for the body in question, to the set of
constraints and evaluating the linear program. Other possible “what-if” analyses include
grounding a part (i.e. setting 0rr=v and 0
rr=ω for that part) and obtaining the instantaneous
degrees of freedom for all the other parts.
The space of allowed motions can be represented by the set-theoretic sum of the
space of motions that preserve the contact ( 0rr
=VJassembly ), and the space of motions that
break the contact ( 0rr
>VJassembly ), where Vr
is the vector of generalized velocities:
breakingcontactpreservingcontactallowed SSS −− += (6.35)
Scontact-preserving is the space of possible generalized velocity vectors that cause all contacts
to be maintained, or:
108
)( assemblypreservingcontact JNullspaceS =− (6.36)
The basis vectors of the nullspace completely describe the possible contact-
preserving motions. A singular value decomposition of Jassembly is used to compute the
nullspace.
Computing the boundary of the space of contact-breaking motions is a much harder
problem. Avis [13], Avis and Fukuda [12, 14], Motzkin et al. [92], Bremner et al. [25], and
Fukuda and Prodon [57] have all proposed methods to enumerate the boundary of a
polyhedral convex cone. However, time requirements for these methods quickly explode
when confronted with cones of increasing dimensionality. Nemhauser and Wolsey [98]
show that the extreme ray membership problem for a cone is in NP. Similar conclusions
are drawn by Avis [15]. For a discussion of the complexity class of enumeration problems
see Fukuda [56].
Given a cone, it is possible to verify the feasibility of a given solution in polynomial time
[98]. Therefore, we propose the following heuristic to construct a finite set of feasible
solutions from the geometry of the assembly:
1. For every primitive contact patch, pick the axis and a position on the axis - for
planes, the normal to the plane; for cylinders and cones, the principal axis; for
spheres, any axis; in addition, pick a second axis tangent to the direction of curve
parameterization – for planes, an axis lying in the plane, for cylinders and cones,
the axis of the base; for spheres, any axis perpendicular to the first axis.
2. See if a translational velocity along and/or a rotational velocity about these axes are
feasible solutions to the set of non-penetration conditions.
109
3. Since there are a finite number of patches, therefore a finite number of axes, the
number of possible feasible solutions will be finite. Note that this heuristic will fail to
detect degrees of freedom that are not along axes of symmetry.
Introduction of domain-specific knowledge (geometric information, in this case),
enables us to draw useful inferences about the space of allowed motions. The feasible
solutions that emerge from this test, along with the nullspace of the cone, form a
representation of the cone. Feasible solutions for a particular pair of parts can be
combined to form joints between parts.
Figure 6.6. 4-part assembly with 3 degrees of freedom.
110
6.6 Illustrative Examples
6.6.1 Example 1 (Arm): Demonstration of the Framework
In order to illustrate the framework defined in the previous sections, we present an
example assembly. The assembly in Figure 6.6 is a 4-part assembly, with three functional
degrees of freedom. We choose to render the base immobile (i.e. we ground it), by
constraining all the six degrees of freedom.
The system is implemented in C++, using ACIS as a solid modeller, and with Open
Inventor for 3-D visualization [62]. This example problem was solved on a SUN Ultra-2
computer running Solaris 7, using 16 seconds of CPU time, from input of the CAD models
to output of the joint information for the assembly.
Contact analysis indicates that this is an open-chain assembly, with 9 linear-boundary
planar contacts (base-to-arm, arm-to-slider and slider-to-rotor), 1 curved-boundary planar
contact (base-to-arm), 8 partial cylindrical contacts (base-to-arm, arm-to-slider and slider-
to-rotor). This generates a total of 81 inequalities, linear in 18 variables forming the
relative translational and rotational velocities (assuming the base is grounded).
The 81 constraints define a polyhedral convex cone in 18-dimensional space (see
Figure 6.7). The matrix representation can be partitioned into two: the nullspace and the
interior boundary enumeration representation. Singular value decomposition returns a
rank of 15, indicating that there are three completely unconstrained degrees of freedom
(and as a result, the nullspace is 3-dimensional). The nullspace basis [N1, N2, N3] is shown
in Equation (6.37).
111
[ ][ ][ ]
1
2
3
0 0 0 0 0 0 1 0 1 0 0 0 1 0 1 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 17 0 1 0 1
0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1
where
i x y z x y z x y z x y z x y z x y z
Arm Slider Rotor
N
N
N
N v v v v v v v v vω ω ω ω ω ω ω ω ω
== −=
= 14 4 4 4424 4 4 4 43 14 4 4 4424 4 4 4 43 14 4 4 4424 4 4 4 43
(6.37)
Nullspace basis vector N1 indicates the presence of a translational degree of freedom
for the slider and rotor with respect to the base. This freedom is at a 45° angle to the
horizontal plane, indicated by the equal infinitesimal relative translational motions in the x
and z directions. Basis vector N2 indicates that there is a relative instantaneous rotation of
the rotor with respect to the base at a 45° angle to the horizontal plane. The [0 –17 0]
translational component stems from the fact that the instantaneous rotation is not about
the origin, but instead about the axis [1 0 1] through the point [18 0 1].
For the instantaneous velocity of the body to be zero at the point [18 0 1],
0rrrrr =×+′= pvvtotal ω (6.38)
or:
[ ]0170 −=×=′ ωrrpv (6.39)
where v′ is the translational component, namely [0 –17 0]; ωr is the instantaneous angular
velocity component, namely [1 0 1]; and pr is the locus of positions that satisfies Equation
(6.39). Thus, we get an axis [1 0 1] passing through [18 0 1]. Thus, nullspace analysis
describes the boundary of the cone.
112
Feasible solutions are constructed from the contact patches. The 18 primitive patches
result in 216 candidate feasible solutions. Each candidate is tested to determine if it is
within the space of allowed instantaneous motion. Four candidates are found to be valid
solutions. Of the four valid solutions, three are identical to the nullspace basis vectors. The
fourth is [0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0], corresponding to the contact-breaking motion
(vertical translation along the z-axis) between the base and the other 3 parts.
Once valid feasible solutions are available, it is possible to group them together to
define joints between parts in the assembly. One of the feasible solutions in this example
results in a revolute joint being formed between the base and the arm (see Figure 6.8).
This joint information is added to the representation of the assembly. Once joints are
Figure 6.7. Formation of the Matrix Representation.
113
detected automatically, information about the material properties can be combined with
kinematic information to perform motion simulations.
6.6.2 Example 2 (1-DOF 4-Bar Linkage): Global Constraint Resolution
To verify the correctness of our implementation, we compared the results of our
system to the analytical formulation for a 4-bar linkage. The example in this subsection is
a 4-bar assembly with 1 degree of freedom (see Figure 6.9) with each bar having a joint
axis-to-joint axis distance of 39 units.
Computing the contact surfaces from the CAD model indicates that there are 4
contacts between the bars, each shaped like a “top hat”. Each top hat contact has 2
Figure 6.8. Mapping feasible solutions to assembly joints.
114
planar contact surfaces bounded by a curved boundary and 1 complete cylindrical contact
surface. The two planar contact surfaces constitute the top and the rim of the hat. The
cylindrical contact surface constitutes the side of the hat. The non-penetration condition is
satisfied everywhere on the cylindrical contact surface if it is satisfied at 6 points at the top
and bottom boundary of the surface. On the two planar contact surfaces, we select 109
points that approximate the boundaries of the surfaces, and impose the non-penetration
condition at these points. This results in a total of 114 inequalities per pair of bars, for a
grand total of 460 inequalities in 18 relative translational and rotational velocity variables
(assuming that Bar 1 is grounded).
The inequalities are used to construct the inequality coefficient matrix A (similar to the
one in Figure 6.7). Each inequality becomes a row in the matrix, resulting in a matrix of
size 460×18. The matrix has a rank of 17. Therefore, the nullspace N is 1-dimensional,
indicating the presence of 1 completely unconstrained degree of freedom. A basis vector
for the nullspace of A is:
Figure 6.9. 4-Bar Linkage
Bar
Bar Bar 3
Bar
115
[ ]
=
−−=
44444 344444 2144444 344444 2144444 344444 21432Bar
1
1
where10000000000391000390
Bar
zyxzyx
Bar
zyxzyxzyxzyx vvvvvvvvvN
N
ωωωωωωωωω
(6.40)
Breaking one of the bar-bar contacts would have resulted in an open-chain assembly,
with 3 more degrees of freedom. The closed-loop eliminates these extra degrees of
freedom, and this is reflected in the 1-dimensional nullspace. Examining the nullspace, we
see that for an unit instantaneous rotation of Bar 4 with respect to Bar 1 about the z-axis,
Bar 2 undergoes a unit instantaneous rotation about the z-axis, but at a position of [39 0 0]
(using Equation (6.39)). Bar 3 undergoes an instantaneous pure translation along the x-
axis of a magnitude 39 times that of the rotation.
The 4-bar linkage has been extensively studied by mechanism theorists. Its behavior
is well known. From [108] (see pp. 233-234), we see that the “velocity-loop equation”
written for our 4-bar linkage is:
0
0
3
24 rrrrr
==−
ωωω
L
LL
(6.41)
where L is the length of the bar, 2ωr is the angular velocity of Bar 2 with respect to Bar 1,
3ωr is the angular velocity of Bar 3 with respect to Bar 1, and 4ωr is the angular velocity of
Bar 4 with respect to Bar 1. Thus, 2ωr is equal to 4ωr and 3ωr is zero. Since the links are
rigid, for every δθ rotation of Bar 2 and Bar 4, there must be a δθL x-axis displacement
of Bar 3. This is identical to the previous result. This validates our implementation of
degree of freedom extraction.
116
6.7 Discussion
The geometry of the parts in an assembly restricts how they can be assembled, and
how they move relative to one another. This in turn influences their static stability,
kinematic behavior, and dynamic performance characteristics. However, models for these
phenomena do not exist initially. The designer provides joint information at the conceptual
design stage to meet certain functional requirements of the assembly. This information is
provided either by specifying kinematic constraints between parts as annotations to the
assembly CAD model, or by specifying mating conditions between specific features on the
parts. It can also be derived from the CAD models of the individual parts, and from the
relative positions of these parts in the final assembly. Or the information could be obtained
by some combination of designer input and automatic derivation. Therefore, there can be
two types of constraints between parts, namely, constraints introduced by the designer to
satisfy functional requirements of the assembly, and constraints induced by the geometry
of parts in the assembly. Both these types of constraints interact to produce a resultant
behavior of a joint. It is important to be able to derive the joint behavior from the CAD
model, as well as to verify that designer input is consistent with the CAD model.
Our method reasons on the CAD model of the assembly to obtain the instantaneous
degrees of freedom. It is able to handle incomplete curved geometry, while at the same
time resolving global (i.e. multi-part) constraint interactions. Linear algebra-based
constraint models are derived directly from CAD models, and then converted into
articulation representations suitable for assembly planning and motion simulation. A
proposition and other supporting theorems enumerate the properties of the contact
117
surfaces between the parts that must be satisfied to construct a linear algebraic constraint
model.
The linear algebra-based constraint model can be used to provide designer feedback.
The model describes the space of allowable instantaneous motion in the assembly.
Although solving for the complete boundary of this space is thought to be in NP, whether a
particular instantaneous degree of freedom is within the space can be verified in
polynomial time. Therefore, our framework also supports the ability to query the model
with the designer specified joint information to verify that the information is correct.
We validated our method by applying it to the 4-bar linkage, and comparing the results
with those obtained from mechanism theory.
Under certain circumstances, our method breaks down: contact surfaces that are
represented by polynomial or transcendental functions have to be approximated as
piecewise planar, cylindrical or spherical contacts – this approximation may remove a
degree of freedom. A valid candidate degree of freedom may not be detected if the
freedom does not lie along an axis of symmetry. Our method is applicable only to
assembly geometry that is modeled by exact CAD models without fit tolerances. The
method is also only applicable to the particular mechanism configuration that is captured
in the CAD model.
6.8 Conclusions and Future Work
This section forwards the state-of-the-art in the following ways:
Exact Treatment of Curved Geometry. Previous work on the application of linear
programming techniques to the contact mechanics between two surfaces was restricted to
118
handling planar surfaces only [86, 88]. Curved surfaces were handled by approximating
them as planar facets, or by using graphical methods. This result was extended to curved
surfaces whose boundaries possess certain properties. The vast majority of manufactured
parts have contacts that possess such boundaries. Therefore, the work presented here
allows a designer to analyze and design devices that contain parts (or components) that in
turn contain a broad class of curved surfaces.
Modeling Support For Kinematics Behavior. Solving the contact conditions at the
boundary will enable the designer to obtain the instantaneous degrees of freedom of the
device. Using generate-and-test methods and reasoning about the geometry of the artifact
will reveal the bounds on the values of the degrees of freedom. Such information, when
combined with information about the mass distribution and with friction models, will allow
the designer to determine the stability of the device, handle articulation during assembly
planning, during synthesis of part geometry, as well as during the operation of the device.
Accurate and Automatic Simulation Synthesis. Simulation of the operation of the
electromechanical device requires kinematic and dynamic information. Since the CAD
model of each component incorporates such information, high-fidelity simulation can be
created and executed with minimal user interaction.
Interesting research issues remain with regard to the handling of model uncertainty
and in the quantification of the effect of model approximations, such as the discretization
of curved planar contact boundaries, on the final result of the articulation analysis.
119
7 Case Study: MEMS-Based Resonator
7.1 Introduction
Microelectromechanical systems (MEMS) have become popular in recent years as
they provide low-cost, high-performance and reliable alternatives for traditional
electromechanical systems. MEMS devices are manufactured using semiconductor
manufacturing processes. They combine electrical and micro-scale mechanical
components on the same silicon die. This allows them to enjoy the economies of scale
prevalent in the semiconductor industry.
The modeling and design of MEMS devices has proceeded along the lines of VLSI
CAD [146]. Both electrical and mechanical components are modeled as port-based
objects and are connected together in a configuration. In many cases, the mechanical
components exhibit behavior only in the plane of the chip, and therefore the model
equations are greatly simplified.
In the previous chapters, we introduced the paradigm of simultaneously designing and
simulating electromechanical systems. In this chapter, we will describe the virtual
Few things are harder to put up with than the annoyance of a good example. Mark Twain
When we get to the very, very small world (… ) we have a lot of new things that would happen that represent completely new opportunities for design.
Richard P. Feynman, from his famous talk titled “There's Plenty of Room at the Bottom” on December 29th 1959 at the annual meeting of the
American Physical Society.
120
prototyping process for a MEMS-based accelerometer. We will apply our virtual
prototyping framework to the design and simulation of this device. We will illustrate the
merits of the COINSIDE methodology. We will only consider the mechanical and
electromechanical design of the virtual prototype, and will not address the analog and
digital electronics design aspects.
7.2 Product Overview
7.2.1 Function and Structure
The measurement of acceleration has a wide variety of applications in the industrial
world [22]. Acceleration sensors are used in crash detection for air bag deployment in
cars, vibration analysis in industrial machinery, etc. Recently, traditional accelerometers
are being replaced in a few applications by MEMS-based accelerometers because of
performance, weight and power consumption considerations.
MEMS-based resonant accelerometers (sometimes referred to as vibrating beam
accelerometers) have a proof mass that loads two vibrating suspensions on opposite
sides of the proof mass [163]. When the accelerometer proof mass is loaded, one
Figure 7.1. Resonator mechanical structure.
121
suspension is put into tension and the other into compression. These suspensions are
continually excited at frequencies of tens to hundreds of kilohertz range when unloaded.
As a result, when "g" loaded, one suspension’s frequency increases while the other
suspension's frequency decreases. This difference in frequency is a measure of the
device's acceleration. This form of accelerometer is an open-loop device, in that the proof
mass is not rebalanced to its center position when force is applied. For accuracy, it relies
on the scale-factor stability inherent in the material properties. Fabrication techniques
result in low-cost, highly reliable accelerometers with a measurement accuracy of better
than 100-µg bias error. Quartz and silicon micromechanical resonator accelerometers are
being developed in the industry. They have proliferated widely into several commercial
(e.g., factory automation) applications.
Consider the resonator structure in Figure 7.1. It is a device constructed out of silicon.
It contains a central proof mass that is mechanically rigid. The proof mass is attached at
either end to electrostatic drives. The movement of the proof mass is restricted by four
spring suspensions symmetrically placed about the mass. The springs and the stators of
the drives are anchored to the substrate. The springs themselves are constructed out of
Damper model
Spring model
Mass model
Force Source
x&
Damper model
Spring model
Mass model
Force Source
x&
Figure 7.2. Fundamental model for the mechanical response of an accelerometer [123].
122
flexible beams of silicon. For the purposes of this example, the anchors are considered to
be rigid.
The electrostatics in the resonator are confined to the comb drives at either end of the
resonator. Each drive has fingers that overlap with each other. The drive has two
parts the rotor attached to the proof mass and the stator attached to the anchor, with an
air gap between them [145]. When a voltage is applied across the rotor and the stator, a
capacitance is created that results in an electrostatic force.
The drive can also be operated as a sensor. A relative movement between the rotor
and the stator results in a change in the capacitance between them. As a result, the
voltage between the rotor and stator also changes. The voltage is measured and
converted to the position of the proof mass using analog and digital electronics.
7.3 Initial System Architecture and Model
The high-level function of the resonator can be mapped to multiple sub-functions. The
sub-functions correspond to “provide inertia”, “provide flexural stiffness”, “actuation”, and
“fix to wafer”. They are then mapped to one or more system architectures. The framework
Mass Spring
Actuator
Wafer
SignalGenerator
Mass Spring
Actuator
Wafer
SignalGenerator
Figure 7.3. Resonator system architecture.
123
for this mapping is the subject of current research [80], and is not within the scope of this
thesis.
We will assume that a system architecture has been generated from the functional
description. The system architecture under consideration is shown in Figure 7.3. It
consists of a mass attached to the wafer substrate through a spring suspension, and
actuated by an actuator. The actuator is driven by a signal, and acts as a damper across
the spring.
The physical behavior of the resonator structure occurs in three
domains mechanical, electrical and electrostatic. A high-level model for each of these
domains captures the overall behavior of the resonator.
The mechanical behavior of the accelerometer can be modeled as an inertial mass
attached to a spring suspension, and the motion damped by a linear damper. The
behavioral model is shown in Figure 7.2. The spring model provides a restoring force with
a stiffness of k. The force in the damping model is found by multiplying the velocity of the
mass by the damping constant b. These two forces oppose the motion of the inertial
mass, which is represented by an mass model of mass m. The input to this system is the
external force on the inertial mass.
Electrically, the proof mass behaves like a resistor. Since silicon is an electrically
conductive material, the structure can be modeled as a network of resistors. Applying a
voltage difference between two points on the structure results in a current flow through the
resistor network.
124
The electrostatics behavior of the resonator is confined to the comb drives. The rotor
and stator are separated by an air gap. A voltage difference applied across the gap results
in a translational motion. Conversely, a translation will give rise to a measurable voltage
difference between the rotor and the stator of the drives.
The mechanical and electromechanical modeling of the resonator involves modeling
the geometry of the proof mass and the spring suspensions, as well as the comb drives.
We will approach this by applying our modeling methodology to the design shown in
Figure 7.1. The Modelica models are presented in Appendix C.
7.4 Initial Design and Modeling
Our framework supports the configuration of components in the virtual prototype by
instantiating and connecting them. So the first step is to select the components that will
constitute the virtual prototype.
The initial design is a configuration as shown in Figure 7.3. The designer decides that
the springs will be placed symmetrically about the mass, and that there will be two
Mass Spring
Actuator
Wafer
SignalGenerator
Mass Spring
Actuator
Wafer
SignalGenerator
Figure 7.4. Design with expanded ports.
125
actuators. The design is refined by adding attributes to the ports so that they become
aggregate ports. The iterated design is shown in Figure .
Once the configuration is complete and all component interfaces are connected, the
designer proceeds to the modeling layer to select behavioral models.
The choice of behavioral model depends on the design stage and the requirements of
the simulation. The physical behavior of the resonator structure occurs in three
domains mechanical, electrical and electrostatic. A high-level model for each of these
domains captures the overall behavior of the resonator.
At this early stage of design, geometric information about the resonator is not
available. The mechanical behavior of the accelerometer can be modeled as an inertial
mass attached to a spring suspension. The spring model provides a restoring force with a
stiffness of k. The input to this system is the external force on the inertial mass.
The designer considers a 1D model for the spring one with flexibility along 1 axis. A
model for the spring is a stiffness coefficient that defines the spring force as a linear
function of the displacement:
F Kx= (7.1)
where F is the generalized restoring force, x is the displacement, and K is the stiffness
coefficient. At this stage some simulation of the fundamental model of Figure 7.2 is
possible.
The designer elaborates the spring into a 2D model. The cross-axis behavior of the
spring can be described using an ideal model. The stiffness coefficient of Equation (7.1)
now becomes a stiffness matrix. The force response of the spring is now modeled along
two orthogonal directions:
126
F Kx=r r (7.2)
where Fr
is the generalized restoring force vector, xr is the state vector, and K is now
a 2×2 stiffness matrix..
Electrically, the proof mass and the springs behave like a resistor. Since silicon is an
electrically conductive material, the structure can be modeled as a network of resistors.
Applying a voltage difference between two points on the structure results in a current flow
through the resistor network.
The electrostatics behavior of the resonator is confined to the comb drives. The rotor
and stator are separated by an air gap. A voltage difference applied across the gap results
in a translational motion. Conversely, a translation will give rise to a measurable voltage
difference between the rotor and the stator of the drives.
When modeling is complete, it is possible to simulate the virtual prototype by
translating the behavioral models into Modelica and evaluating them in Dymola.
Further refinement of the design and system-level model requires a suite of component
objects that contain CAD data and behavioral models. Till this stage in the design,
geometry was not available to the designer. To proceed further in the design process, he
defines a library of commonly used MEMS component objects, based on our methodology.
7.5 Modeling Methodology: COINSIDE with Modelica
In previous chapters, we presented our framework for virtual prototyping. We use
Modelica [89] to represent the behavioral models in the virtual prototype. In this section,
we will briefly describe Modelica and some of the characteristics of our Modelica models.
127
Modelica is an important effort to define advanced simulation languages capable of
modeling complex multi-disciplinary systems. It has been developed primarily by the
continuous systems community in Europe. It supports continuous time and discrete time
modeling in multiple energy domains, and declarative modeling and hierarchical
encapsulation.
In addition, Modelica has the advantage that it is truly object-oriented with support for
model inheritance and sub-typing. It further allows the definition of aggregate ports in
which multiple across, through, and signal variables from different energy domains can be
combined.
Modelica is currently only supported by Dynasim [44]. Through symbolic index
reduction, their solver is capable of handling index-3 problems that are common in
mechanical models. (The index of a system of DAEs is the minimum number of
differentiations required to obtain an equivalent explicit system of ordinary differential
equations [11]).
Modeling with Modelica is different from modeling with NODAS in several ways.
Differences are in how Modelica models can be used to hierarchically model systems, the
nature of ports, and in 6 DOF mechanical modeling.
Modelica system models can be embedded easily in larger system models. A
component, called the MEMSInertialSystem, is always present in all system
configurations. This component has one connector and assigns the positions and linear
velocities at the connector to be zero. Accelerations and angular velocity can be set as
parameters. All other components are placed relative to this component. Such a construct
128
allows the designer to design a MEMS system and then place the entire system within a
larger system, such as that of a car or a satellite.
Modelica ports, called connectors, contain the positions and force vectors, as well as
the velocity and acceleration vectors at the port location. Positions are defined in global
coordinates, while velocities, accelerations and forces are defined in a local coordinate
frame attached to the port.
The Modelica multibody systems library is designed for 3D geometries. However, in
this thesis we implement a 2D MEMS library that is similar to the NODAS methodology.
NODAS (Nodal Design of Actuators and Sensors) [52, 95] is a MEMS modeling
methodology that is based on composition via ports. Components are connected to each
other via the ports in their interface. Components are called cells that contain multiple
cellviews, one for layout (or geometry), one for the schematic (or configuration), and one
for the behavioral model. Additional cellviews can exist that are specific to a particular
modeling language or solver.
Models capture the mechanical and electrostatic behavior of MEMS components in
the same representation as that used for the electrical and electronics components in the
design. Models are based on physical laws and are calibrated and verified against finite
element simulations. The models can be at multiple levels of detail, and depending on the
experiment, appropriate models are selected for the system-level configuration. NODAS
contains models for substrate anchors, Euler beams, rigid plates, electrostatic gaps [83],
viscous, squeeze film [154] and Couette damping, and comb drives. These models are
configured in the schematic to create system-level models for MEMS devices.
129
Other design tools like layout extraction tools and optimization tools are also provided.
Some integration between layout (form) and model (behavior) parameters is present.
Feature recognition is used to recognise and extract some parameters from the layout into
the schematic in Cadence [16, 17]. The inverse problem, namely to create a layout given
a system-level schematic is also addressed. Optimization tools have been used to select
optimal parameters for MEMS systems such as comb drives [73, 93, 96].
The models are implemented as Verilog-A models in Cadence [27]. Discipline-specific
physical constants are collected into a single file. Manufacturing process-specific
information is collected into another file. These files are read into those models that
require process or discipline-specific constants. A 2D version of NODAS has been
released, and a 3D version is in development.
7.6 The COINSIDE MEMS Library
7.6.1 The MEMS Connector
The MEMS connector (Figure 7.5(a)) captures the mechanical interaction between
components in the prototype. It is a 2D port and captures only mechanical motion in the
plane. Modelica mechanical connectors are vectors they encapsulate the linear and
angular positions, velocities, accelerations, forces and torques at the location of the
connection point. When a connection is made between two connectors A and B, the
following equations hold:
130
,,,
A B A B
A B A B
A B A B
p p R Rv va a
ω ωα α
= == == =
v vv v v vv v v v
(7.3)
where , , , , ,i i i i i ip R v aω αv vvvv are the translational and rotational positions, velocities, and
accelerations, respectively, of connector i, and
00
A B
A B
F Fτ τ
+ =+ =
r r v
(7.4)
where , , , , ,i i i i i i
across through
p R v Fω τvv vv v14243 are the mechanical connector variables for port i.
(a) (b) (c)
MEMS Connector MEMS Substrate Inertial Mass
(d) (e) (f)
MEMS Anchor Beam Element Electrostatic Gap
(g)
(h) (i)
Cut anchor External Force Transformation
Figure 7.5. Basic MEMS component objects and component interactions.
131
The port has an orientation. The right vertex of the triangle points towards the x-axis,
with the y-axis pointing upwards. This results in a right-handed coordinate frame at the
port.
When connections are made between MEMS connectors, it is assumed that the two
connected ports are in the same orientation. To change orientations between ports, a
MEMS Transformation interaction (Figure 7.5(i)) is necessary so that a relative rotation
and/or translation can be established between the connectors. We have designed our
components so that, in general, it is not necessary to use the Transformation interaction to
change the orientation of the connector.
7.6.2 MEMS Component Objects
Our component objects are modeling representations of the MEMS structures used to
construct the resonator hierarchically. They include the substrate (Figure 7.5(b)), the
beam component (Figure 7.5(e)), the anchor component (Figure 7.5(d)), a generic mass
component (Figure 7.5(c)), the rigid plate component (Figure 7.6) and the comb drive
component (Figure 7.6).
132
The components represent distinct physical portions of the resonator structure. They
encapsulate a simple geometrical description and a behavioral model. The geometrical
description is limited to the dimensions of the bounding box of the component this is
sufficient for our limited purposes since the MEMS fabrication process usually creates
rectangular structures.
We take advantage of the object-oriented capabilities of Modelica in defining
components. We define two base classes of components, those with a single MEMS
connector (such as the substrate and the mass), and those with two MEMS connectors
(such as anchors and beams and transforms). We inherit these base classes and
specialize their behavior to represent each specific child component. We also use the
Rigid Plate Comb Mass Comb Drive C
ompo
nent
Con
figur
atio
n
Figure 7.6. Compound components.
133
encapsulation capability to separate the component into an interface section and a model
section.
The MEMSInertialSystem component models the substrate of the chip. This acts as
the chip frame of reference. The entire structure is connected to this component via the
anchors. The interface for this component contains one MEMS connector and is inherited
from the corresponding base class. The model for this component assigns the positions
and velocities to be zero. We allow accelerations to be user-defined, so that the entire
chip along with the MEMS structure and electronics can be placed in an accelerating
reference frame such as a car or a satellite and simulated.
The anchor component models the locations of fixed silicon on the substrate. The
MEMS structure is attached via anchors to the substrate. The anchor is a two-MEMS
connector component one connector is connected to the substrate
(MEMSInertialSystem) component and the other is connected to the structure. The anchor
model merely defines the relative velocities, accelerations and linear positions between
the two MEMS connectors to be zero. It also requires that the forces and torques on the
anchor sum to zero, since the anchor has no inertial properties. The anchor is
parameterized so that the user can assign a relative z-axis rotation between the
connectors. This is important for the correct orientation and placement of the structure on
the substrate.
The use of fixed locations in a mechanical system-level model can result in kinematic
loops. Our resonator design (Figure 7.1) has 6 anchors. To solve this problem, we follow
the Modelica methodology and introduce the concept of a cut-anchor (Figure 7.5(g)) that
134
establishes the same relationships between the velocities and accelerations and forces
and torques as the regular anchor component. We also use a special Modelica function
that tells the solver to constrain the relative positions to be as close to zero as possible.
This function also communicates to the solver that the velocities and accelerations are the
first and second time derivatives, respectively, of the positions. This breaks the kinematic
loop and creates a correct simulation model.
The generic mass component models a lumped mass attached to the environment at
its center of mass. Damping is modeled as linear viscous damping that is anisotropic in
the x and y directions. The damping force along each direction is linearly related to the
velocity in that direction through a damping coefficient in each direction. The damping
coefficient B has the general form:
,x yLw
Bd
η= (7.5)
where η is the viscosity of air at room temperature, L and w are the dimensions of the
mass (assumed to be rectangular) and d is the air gap between the structure and the
substrate. Newton-Euler equations are applied at the center of mass:
Property Value
Density in 3kg
m 2330
Young’s Modulus E in Pa 165×109
z-axis thickness in m 2×10-6
Sheet resistance in ohm 10 Figure 7.7. Material properties of poly-silicon.
135
, F ma Bv Iτ α= + =r r r r r (7.6)
where Fr
is the force vector, τr is the torque vector, ar is the linear acceleration vector, vr
is the linear velocity vector, α is the angular velocity about the z-axis (out of the plane of
the substrate). m and I are the mass and moment of inertia parameters, respectively, and
B is the diagonal damping matrix with ,x yB as the terms along the diagonal.
The beam component represents long and slim Eulerian beams that are flexible, and
is parameterized by its length and width. The component is a configuration of a stiffness
model and a lumped mass model attached to the center of the beam. The stiffness model
is linear in the displacements:
F Kx=r r (7.7)
where Fr
is the generalized force vector, xr is the state vector, and K is the stiffness matrix
chosen appropriately for the selected state variables. We chose our state variables to be
the linear displacement in the local y direction with respect to one end, and the rotational
displacement. The stiffness matrix is:
3 2
2
612
6 4
EIEIL LK
EI EILL
− = −
(7.8)
where E is the Young’s Modulus for silicon (Figure 7.7), I is the second moment of area
and L is the length of the beam. The complete beam model can be expressed as:
F Kx Bx Mx= + +r r r r& && (7.9)
136
Where xr is the state vector of the beam. The Electrical behavior of the beam is like a
resistor with the resistance computed from the dimensions of the beam.
We performed some simple tests on our beam model to verify that the behavior was
similar to the NODAS beam model. We anchored the beam at one end and forced the
other end with a sinusoidally varying force of frequency 1 Hz and amplitude 1 µN. The
results are shown in Figure 7.8, and correlate well with the corresponding NODAS
simulation. The animation viewer is also shown on the extreme right of the figure, with the
beam displayed as the thick horizontal line. This viewer is used as a primitive layout
verification tool.
The plate component represents large, rigid, conducting plates and is parameterized
by its length and width. It has twelve attachment points, each represented by a connector.
Four of the connectors are located at the center of each of the sides of the plate. The
other 8 connectors are symmetrically placed at an offset from each corner of the plate. We
model the behavior of the plate with a Mass component at the center of the plate attached
by Transform components to the twelve MEMS connectors on the boundary of the plate
(Figure 7.6). The electrical behavior of a plate is the same as a network of resistors,
Figure 7.8. Simple cantilever beam configuration, Modelica output and layout verification.
137
attached at the twelve connections points along the boundary.
The comb mass component (Figure 7.6) is a child of the OneMEMSConnector
component that represents the fingers of the rotor (or stator) of the comb drive along with
the truss to which all the fingers are attached. It is parameterized by the truss thickness,
number and length of fingers and the gap between fingers. From these parameters, the
mass and inertia properties are calculated. A Mass component is instantiated with these
parameter values. Comb mass components are used only in the comb drive configuration.
The comb drive component (Figure 7.6) is a child of the TwoMEMSConnectors
component. It represents the electrostatic comb drives in the resonator and is
parameterized by the number and size of the fingers, the gap between fingers and the
overlap between fingers, along with parameters representing the truss that supports the
fingers. We model it as a configuration of two Comb mass components and an
electrostatic gap interaction model. The two comb masses are not kinematically
constrained with respect to each other. Their only physical relationship is through the
electrostatic force exerted on them from the gap interaction model.
138
The damping phenomena in MEMS systems can be classified into 3 types: Stokes
flow above the structure, linear Couette damping between the structure and the substrate,
and squeeze film damping when the air film is squeezed between two moving structures.
These models are used in detailed comb drive configurations where there is relative
motion between the rotor and stator portions of the drive. For simplicity, in this thesis we
do not model Couette and squeeze film damping in the drives.
The spring suspension components represent the U-spring suspensions on either side
of the proof mass of the resonator. They are modeled as configurations of beam and plate
components (Figure 7.9). The long beam in the spring allows flexure in the y-direction.
The small plates act as rigid joints that allow for moment and force transfer from one beam
to another. We do not model rigid joints as mechanical interactions, since this is the
default interaction model that is created when two MEMS connectors are connected with
each other.
Right U-Spring Left U-Spring
Com
pone
nt
Con
figur
atio
n
Figure 7.9. Spring suspensions
139
We use several standard components from the Modelica electrical library voltage
sources and resistors. Their design and modeling is not the focus of this thesis, therefore
we do not elaborate on their models. See Appendix C for the corresponding Modelica
models.
7.6.3 MEMS Component Interactions
Component interactions capture the physical phenomena at the interfaces between
connected component objects. They do not represent any physical entity in the device, but
depend on the interfaces of the connected component objects. In the resonator, the
interaction phenomena are mechanical interactions between components, electrical
connections between components, and the electrostatic interaction within the comb drives.
The mechanical interactions in the structure are the rigid joints between components
and the transforms between MEMS connectors. As stated previously, we do not
instantiate interaction models for the rigid joints since the default interaction model is that
of a rigid joint, represented by Kirchhoff’s laws. We define a Transformation interaction
that captures the relative transform between two MEMS connectors. The interaction is
parameterized by the displacement vector x yr r r = r in the plane and the relative
rotation relθ about the z-axis. The interaction model is used to model the mechanical
interaction between the mass of the plate and the boundary of the plate.
Damping is an important mechanical interaction that occurs when there is relative
motion between mechanical components in the presence of a viscous medium like air.
However, in this example we do not treat is as a separate interaction model, and instead
140
lump it into the behavioral model for the mass component. We will discuss damping in the
Discussion section.
The electrical interactions in the structure are the default electrical connections
between conducting components. The interaction model is merely Kirchhoff’s laws and is
automatically instantiated by Modelica.
The electrostatic interactions are localized to the comb drive, and occur between the
stator and the rotor. We capture the interaction using an electrostatic configuration port
(Figure 7.10). This port contains a mechanical and an electrical modeling port. The
location attribute points to the CAD feature that represents the fingers of the drive. The
material at the location is silicon. The intended use for this port is in a comb drive for the
purpose of energy conversion, and is captured in the Intended Use attribute.
ElectrostaticConfiguration Port
Mechanical Modeling Port
Electrical Modeling Port
Location
CAD Feature = Fingers
Material
Name = SiliconProperties
Young'sModulus = 165×109
Density=2330Intended Use
Comb-drive
Convert-energy Figure 7.10. Electrostatic port.
141
The electrostatic interaction model is represented in our attribute grammar in Figure
7.11. When two electrically conducting parts that are separated in space have a voltage
difference across them, a force is generated. As shown below, the force is directly
Material
Modeling Ports
Electrostatic gapInteraction Model
Assumptions
Parameters
Active DomainsElectricalMechanicalSignalThermalHydraulic
Location
Geometry
Invariant
...
Port Map 1 = Port 1:: Electrostatic Port
Intended Usesconvert-energytranslational forcesconstrain-motion
InvariantNon-reactive
Equations
Physical Phenomena
Electrostatic energy conversion
Parallel Plate equations
Port Map 2 = Port 2:: Electrostatic Port
Parents = NIL
Gap fringing
AC
zε= 21
2C
F vz
∂=∂2
C Az z
ε∂ = −∂
Initial gap = 2µm
Initial overlap=6µmFringing parameters
Fringing factor = 0.0
Figure 7.11. Electrostatic interaction model attribute representation.
142
proportional to the spatial rate of change of capacitance between the parts. The simplest
electrostatic gap model is the parallel plate model. We use this model with a scaling factor
to account for fringing effects.
Electrostatic gap models capture the energy conversion between two electrically
conducting parts that have a voltage difference across them and are separated in space.
The simplest electrostatic gap model is the parallel plate model. The capacitance between
two parallel plates at a specified voltage is inversely proportional to the distance between
the plates:
AC
zε=
(7.10)
Where ε is the permittivity of air, A is the area of the overlapping plates, z is the distance
between the plates and C is the capacitance. The electrostatic force generated between
the plates is given by:
212
CF v
z∂=∂
(7.11)
Where v is the voltage difference between the plates, Cz
∂∂ is the space derivative of the
capacitance along the direction of movement and F is the electrostatic force. Cz
∂∂ is
computed from Equation (7.10) as:
143
2
C Az z
ε∂ = −∂
(7.12)
Equation (7.12) is one possible model for the rate of change of capacitance in Equation
(7.11), and we use this model in our electrostatic gap formulation.
7.7 Refinement of Design and Model
To obtain a more realistic simulation, the designer decides that further refinement is
necessary in the components. In this scenario, the designer elaborates the mass and
MassSpring
ActuatorWafer
SignalGenerator
MassSpring
ActuatorWafer
SignalGenerator
(a)
MassSpring
ActuatorWafer
SignalGenerator
MassSpring
ActuatorWafer
SignalGenerator
(b)
U-spring
Folded flexure spring
Figure 7.12. Two design alternatives for the spring suspension.
144
spring components in the configuration layer and selects refined models in the modeling
layer.
The designer considers two design alternatives: a U-spring design and a folded flexure
spring design for the suspensions. For each case, he elaborates the spring component.
The elaborated configurations are shown in Figure (a) for the U-spring and Figure (b) for
the folded flexure spring. He creates embodiments for each candidate spring component
and connects them together in the configuration. COINSIDE automatically connects
together the corresponding CAD models and behavioral models. The geometry for case
(a) and (b) is shown in Figure and Figure , respectively.
Once the configuration is complete, the designer selects behavioral models. The
suspensions are now modeled as flexible beams. The mass is modeled as a combination
of rigid plate models, and the comb drives are modeled as a rotor mass and a stator mass
interacting through an electrostatic port.
This provides all the necessary information to complete the system model and
evaluate it in a Modelica solver. Both design alternatives (a) and (b) are evaluated and
compared by the designer.
Figure 7.13. Resonator mechanical structure for case (a).
145
7.8 Resonator Model
At the system-level, creating the model involves defining an external interface for the
model. Then one selects, instantiates and connects component interfaces from a library of
component objects. Once this is done, behavioral models are selected for each
component. Behavioral models are composed automatically within our framework to
create a system-level behavioral model.
In this case, the resonator interface consists of three electrical pins that connect to the
two comb drives and the main structure. We have the library of component objects and
Figure 7.14. Resonator mechanical structure for case(b).
Figure 7.15. Resonator icon in Modelica. The icon represents the physical layout.
146
component interactions to assemble the MEMS resonator system-level model (Figure
7.15). We select components from the library and connect them together in a configuration
that closely mimics the physical geometry of the resonator. This configuration is shown in
Figure 7.16.
The configuration contains five plate components to represent the main proof mass,
four spring suspension components, one anchor and three cut-anchors for the
suspensions, and two comb drives each with an anchor. There is also a
MEMSInertialSystem component to which all the other mechanical components are
connected. The components are connected via the MEMS connectors and the electrical
connectors to create the system-level configuration.
Figure 7.16. Resonator configuration in Modelica.
147
As a component is instantiated in the configuration, a corresponding physical layout
component is added to represent the geometry of the component. After simulation, it is
possible to watch the motion of the structure in the animation window of Dymola.
7.9 Simulation and Results
The resonator structure shares the same die as the electronics for the MEMS
component (Figure 7.17). The entire chip is mounted within the overall electromechanical
system, such as a car. To simulate the effect of the motion of the car on the resonator, we
can apply an acceleration to the MEMSInertialSystem component which will be
transmitted to all the other components in the resonator. In this chapter, however, we
choose to test the resonator in isolation.
To test the resonator virtual prototype, we embed it in a system-level configuration
along with two DC voltage sources and a voltage-controlled voltage source (Figure 7.18).
Then we select voltages for the sources and simulate the virtual prototype.
Figure 7.17. Resonator test case – embedded in a vehicle.
148
7.10 Design Verification: Finite Element Modeling
MEMS are small, intricate devices that must perform accurately and reliably, often in
the hostile environments of vehicles and industrial machines. As a result, engineers
developing MEMS using port-based modeling methods must rely on finite element
analysis (FEA) software to verify the behavior of these microstructures in determining
stress, de-formation, frequency response, temperature distribution, electromagnetic
interference, and electrical properties.
Figure 7.18. Resonator test case configuration.
149
Another complication in MEMS design is that many physical phenomena interact to
affect the operation of the devices, including mechanical driving forces as well as resonant
behaviors, thermal levels, piezoelectric effects, and electro-magnetic interference. The
way in which MEMS are packaged also can affect the operation, reliability, and accuracy
of the units, compounding the difficulty of MEMS design. Because many of these effects
are interdependent, predicting output and performance of a MEMS device is a complex
problem that defies the intuitive approaches often used in the development of larger
assemblies.
To meet these challenges, MEMS engineers rely almost universally on finite element
simulation to verify their designs. FEM structural analyses determine parameters such as
stress, strain, displacement, and natural frequency vibrations in mechanical parts as a
result of applied loads. Available computational fluid dynamics capabilities handle
problems ranging from laminar, turbulent, and compressible flow to the simulation of
pressure drops, velocities, and thermal distributions. Heat transfer problems involving both
solids and fluids are common in MEMS, since heat buildup is so destructive to electronic
Resonator geometry
Fixed supports Fixed contacts Mesh
Figure 7.19. Resonator FEM model setup in ANSYS DesignSpace.
150
circuits. Electromagnetic analyses are used in cases of devices with electrically or
magnetically generated forces to calculate force, torque, inductance, impedance, Joule
losses, field leakage, and field saturation.
Developers of MEMS also have obstacles to overcome in prototype testing. While
physical mock-ups of conventional electromechanical devices may undergo several test
and redesign cycles, the initial semiconductor fabrication setup for MEMS is very costly
and so time-intensive that prototype testing is almost always performed to validate the
design rather than to identify design flaws.
165.53 x
KHzθω = 200.93 z
KHzω = 249.34 y
KHzω = 340.85 z
KHzθω =
… higher plate modes
355.63 y
KHzθω = 450.77 x
KHzω = 560.63 plate
KHzω =
Figure 7.20. Resonating frequencies for the resonator.
151
An important characteristic of the MEMS structure is its resonant frequencies. When
the structure is loaded with a sinusoidal load of a specified frequency, it vibrates about its
rest position. At particular frequencies, there is energy build-up within the structure that
can cause mechanical fatigue and failure. Designers of MEMS systems design their
structure such that it does not have resonant frequencies in the operating range of their
device.
In this section, we will present results of the FEM analysis to compute the resonant
frequencies of the MEMS resonator structure. We used Ansys DesignSpace 6.0 [10] for
the analysis (Figure 7.19). After importing the resonator assembly into Ansys, we
assigned a fixed support for the bases of each anchor. We specified that the contacts
between components are fixed. We meshed the structure, with a refined mesh in the
springs.
We obtained the resonant frequencies for the structure. They are shown in Figure
7.20. All the frequencies are in the hundreds of KHz. The typical operating frequencies of
such a resonator is tens of KHz. Therefore under normal operating modes, the resonator
will not excite these resonating frequencies. The first 6 modes correspond to the
, , , , ,x z yz y xθ θ θ modes respectively. The 7th and higher modes are plate bending modes
and are neglected.
These results can be verified by performing an AC analysis [71] on the system-level
model of the structure. Dymola does not support AC analysis. We performed the AC
analysis using NODAS, and obtained a zθ resonant frequency of 389 KHz that is within
10% of the results from Ansys. The x and y resonant frequencies from NODAS were
152
532.1 KHz and 254.7 KHz, respectively. These values also correlate well with the Ansys
results.
7.11 Discussion
In this section, we illustrate the benefits of our framework while designing the MEMS
resonator in COINSIDE, while modeling the same physical phenomena as NODAS.
7.11.1 Framework
Our framework makes virtual prototyping easier by defining reusable component
objects and component interactions. Consistency between the design and the model is
maintained during each design iteration. Therefore each design iteration is much quicker.
The reduction in the time for each iteration and sometimes also the number of iterations
means that the designer can evaluate more design alternatives.
Separation of the system-level model into component objects and component
interactions allows easy swapping of models at varying levels of detail. In keeping with this
philosophy, in our framework, users work with icons in COINSIDE that are easier to
understand.
COINSIDE MEMS connectors make the configuration task easier. In COINSIDE,
making a mechanical connection between two components automatically places them in
the correct relative orientation as defined in their ports. COINSIDE is capable of handling
6 DOF motion and the mechanical connectors and models defined in the Modelica
Multibody systems library reflect this capability. Mechanical connectors in the COINSIDE
MEMS library contain vector variables for velocities and accelerations in addition to
153
position and force vectors. Derivatives of position are therefore passed from one model to
another. This helps to avoid index problems.
COINSIDE is cumbersome to use when managing configurations with a large number
of interactions between components. This is because COINSIDE provides only static
membership capability within connector classes.
Consider the damping interaction phenomenon. Damping occurs between any pair of
mechanical structures in a viscous medium, undergoing relative motion, and separated by
a gap. The viscous drag opposes the motion of the structures. In this example, the
damping is a two-port distributed interaction between the mechanical components and the
substrate. Each mechanical component such as the U-spring can contain one or more
lumped masses (Figure 7.21). To model the damping between the U-spring and the
substrate, we would need five damping models, one for each of the five lumped masses.
The U-spring interface would have to be augmented with five “damping” ports to connect
the five masses to the MEMSInertialSystem component. Making similar connections to all
U-springU-spring
SubstrateSubstrate
Damping Interaction Model
Damping Interaction Model
U-spring
configuration
U-spring
interface
Damping port
beam
beam
beam
plate
plate
Figure 7.21. Damping interaction in the U-spring.
154
the other mass components in the system will quickly result in a configuration that is
difficult to manage.
To mitigate this problem, we propose that our port formalism be used to define a
parametric aggregate port to aggregate all the damping interactions into a single
“damping” port (Figure 7.21). The aggregate port is parameterized by the number of mass
components in the configuration. To instantiate the “damping” port, the designer assigns a
numeric value to the parameter attribute of the port. In COINSIDE it is possible to define a
port class that aggregates a fixed number of sub-ports. The aggregate port construct will
significantly reduce the detail present in the configuration, while preserving the complexity
of the representation.
7.11.2 Models
The port across variables in NODAS are interpreted as displacements from the
nominal position. There is an implicit frame of reference attached to the nominal position.
In COINSIDE, each connector has a local frame of reference. Within the connector,
positions are defined as global variables, while forces are local to the frame at the
connector.
As a consequence of this interpretation, NODAS does not understand mechanical
statics. It is possible to connect a beam of length 100 µm between two plates that are 10
µm apart and not have any initial movement to balance the internal stresses generated by
the structure. COINSIDE connectors contain global positions, and therefore do model the
static behavior of mechanical structures correctly.
155
Sometimes COINSIDE configurations will reflect the physical configuration more
accurately than a corresponding NODAS configuration, even though the underlying
models will generate the same results after simulation. For example, we use the cut-
anchor component to break kinematic loops in the resonator. This reflects the fact that a
mechanical structure anchored at multiple points to the ground is statically indeterminate.
Exclusively using anchors in the configuration would result in compile-time errors. This
imposes good modeling practice on the designer.
7.11.3 Modeling Language
COINSIDE uses Modelica as the modeling language. Modelica is not yet a widely
adopted standard. However, there are efforts underway in Europe to popularize Modelica
in industrial modeling environments. Standardization of Modelica will result in the
availability of standardized libraries of components that can be reused across many
designs
Modelica is a truly object-oriented language, with complete encapsulation and
inheritance capability. This makes Modelica a good language to manage large libraries of
reusable components. However, the component management tools provided with the
Dymola software are still relatively primitive and difficult to use.
Modelica supports vector and matrix algebra. Therefore, Modelica models are more
compact and easier to understand, but can sometimes be more difficult to debug.
156
7.12 Summary
In this example, we have used abstraction, both in the configuration and in the
modeling layer. Abstraction serves an important purpose: to reduce the amount of detail
presented to the designer so that he or she can focus on high-level modeling decisions
without dealing with small details.
We used the port grammar to elaborate the intended interfaces of the spring
component objects and the electrostatic interaction models. As the components became
more detailed, the port representation was also refined to accommodate the additional
information that was available at each stage of the design process.
The attribute based representations of ports can be stored in a library. When defining
intended interfaces for component objects or models, the designer can reuse previously
created ports by searching the library based on the desired characteristics of the port.
The port-based modeling paradigm imposes constraints on the types of models that
can be defined. In particular, all ports represent discrete locations on the interface.
Distributed interactions like damping can also be captured within our framework. Instead
of a discrete location, a surface on the interface is involved in the interaction. The entire
surface is represented by an aggregate configuration port. Using the port grammar, we
defined a parametric aggregate port to aggregate all the damping interactions into a single
“damping” port.
Our MEMS component library is rich and detailed enough to create moderately
complex devices. The design process for these devices is simplified and shortened by
using our attribute-based framework.
157
8 Summary and Conclusions
8.1 Summary
In this thesis, we have presented a framework to make virtual prototyping easier and
more accurate. We achieved this goal through composition of components and by
interleaving design and simulation.
To achieve the goal of the thesis, we pursued a two-track approach a formal,
representational track, and an algorithmic track. We defined the building blocks of our
composition the component object and the component interaction model, using formal
grammars. We presented a framework and algorithms to extract component object models
and interaction models from design. We illustrated our ideas using the example of a
complex electromechanical system a MEMS-based resonator.
In this thesis, we used port-based modeling to compose components into systems.
One can think of design as a process that consists of decomposition and composition.
High-level functions are hierarchically decomposed into functions for subsystems; these
sub-functions are then mapped to physical components that are in turn recomposed into a
complete system [105, 127]. During the process of composition (i.e. synthesis), the
Let this be an example for the acquisition of all knowledge, virtue, and riches. By the fall of drops of water, by degrees, a pot is filled. The
Hitopadesa
If you can't describe what you are doing as a process, you don't know what you're doing. William Edwards Deming
158
designer defines which components are used and how they interact with each other. This
process parallels the hierarchical modeling process: models of components are
connected to each other via interaction models (describing the dynamics of the
component interactions) to define the behavior of a system or subsystem. Both processes
are based on hierarchical composition: composition of form in design and behavioral
models in simulation [141, 166].
Many electronic CAD vendors offer close integration between the circuit design
process and the behavioral modeling of these circuits using industry-standard languages.
When the user defines the circuit topology, the corresponding models of components and
component interactions are automatically composed into a system-level model. This can
be easily accomplished because the interactions between the electrical components are
very simple: the voltages of two connecting terminals are equal and the currents sum to
zero.
In this thesis, we provided a framework that extracts mechanical interaction models
from design data and provides feedback to the designer about the kinematic behavior of
his design. In the mechanical domain, parts can interact with each other according to a
variety of connections, such as lower pairs, gear contacts, or rolling contacts. These
connections result in both kinematic and dynamic constraints on the positions of the
interacting parts. The information needed to instantiate these interaction models (the
model structure and corresponding parameters) either can be obtained directly from the
mechanical CAD model, or has to be provided by the designer [33, 81, 124, 128].
159
We defined algorithms that extract mechanical behavioral models from the geometry
of the component object. Some CAD tools, such as Pro/Engineer Behavioral Modeler™
[43], allow for the integration between CAD data and behavioral modeling. By including
evaluation procedures as features in the feature tree, one can automatically perform
behavioral analysis whenever a part or assembly is modified. For example, an evaluation
feature could compute the mass of the design from the CAD geometry and the material
density. Such a tight integration between the CAD tool and COINSIDE is planned for
future versions.
The current research trend is to extend the single-domain integration between design
tools and simulation tools to multiple domains. This can be achieved through component
models [111, 129, 136] that include a description of both the form and the behavior. The
act of connecting two components configures not only the form, but also the behavioral
models of the components. This component-based framework can be extended even
further towards object-oriented intelligent components in which knowledge-based systems
containing design rules are integrated with the CAD and behavioral models [23, 138].
We illustrated our ideas with a MEMS (Micro Electro-Mechanical Systems) example.
MEMS is a domain in which component based modeling has already been demonstrated
[40, 94, 99, 118]. MEMS systems are multi-disciplinary in nature (often consisting of
electrical and mechanical components), and the mechanical behavior can frequently be
approximated as being limited to two dimensions. The resulting mechanical equations are
sufficiently simple to be modeled within the existing modeling paradigms of electrical CAD
tools. In certain simulation experiments, it may be necessary to model the MEMS device
160
not as a collection of rigid bodies, but as a more detailed finite-element model. This is an
area of ongoing research [67, 161].
8.2 Review of Contributions
This thesis forwards the state of the art in the following areas:
1. A new framework for virtual prototyping.
• We define building blocks that make the virtual prototyping process easier.
• We provide a framework for maintaining consistency between form, function
and behavior.
2. Easier and more accurate virtual prototyping.
• We provide a framework for automatic behavioral model composition when
component objects are connected in a configuration.
• We provide a formal basis for the representation of virtual prototypes by
defining an attribute grammar for virtual prototypes.
3. The building blocks for virtual prototyping.
• We expand the definition of a port to incorporate configuration information in
addition to modeling information.
161
We achieve this by defining a new type of port the Configuration Port. We
provide a formal representation for ports and an XML representation of the
attribute grammar for ports.
• We define the Component Object.
The component object is an encapsulation of design data and behavioral
models. We provide a framework for automatic extraction of mechanics
model parameters of component objects.
• We define the Component Interaction.
We provide a framework for automatic extraction of interaction models. We
provide algorithms for automatic extraction of kinematic interaction models.
We provide an XML representation of the attribute grammar for component
interactions.
4. A MEMS modeling library using port-based composition, component
objects and component interactions.
• We define MEMS components and interactions in our library.
• We build a MEMS device with our virtual prototyping methodology.
• We have verified the behavior against finite-element simulations.
162
8.3 Discussion
Port-based modeling has been successfully applied in VLSI CAD. It has just begun to
find acceptance in the design of electromechanical (EM) systems. However, some
aspects of VLSI design may not be applicable to EM design. Whitney [160] compares the
process of electromechanical systems design to that of VLSI design and concludes that
the compositional approach used in VLSI design will have several deficiencies when
applied to EM design. In this section, we discuss how this thesis mitigates some of these
problems.
Electromechanical (EM) systems design may never see the ease of use,
standardization and tight coupling between design and simulation that is prevalent in the
electronic CAD industry. Such coupling may also not be desirable because a design and
simulation paradigm based purely on composition can result in poor EM designs that
consume too much power or take up too much space.
Components in an electromechanical system may perform multiple functions, so that
designs are efficient. However, in VLSI systems, components often implement a single
function so that logical complexity is reduced. A compositional approach to EM design
results in a system-level model where each component performs a single function. Such a
design can be inefficient. It is important to have a framework that can combine several
functions into a single component and then use that component to replace other
components in the system-level model. We believe that it is important to incorporate a
functional modeling paradigm into our framework so that EM designs created with
COINSIDE have better efficiency.
163
EM systems have undesirable side effects such as vibration or friction that are at
significant power levels. EM systems operate at significant power levels, unlike VLSI
systems. A lot of design and analysis effort is expended in discovering and allowing for
these side effects. In VLSI systems, side effects like crosstalk can be designed out by
increasing the line spacing in the layout. As more and more designers use compositional
EM design, the knowledge base of component models will expand greatly. It is important
to be able to organize this body of knowledge for easy search and retrieval. While
performing an experiment, it is also important to automatically select a model that
incorporates the appropriate side effects. We leave these two issues for future research.
VLSI systems do not experience significant backloading that is, they do not draw
significant power from each other, and information flow is in one direction only. This is
because they maintain a very large output to input impedance ratio. This is not true of
mechanical systems. The backloading characteristic is equivalent to the statement that
EM components cannot be designed independently of each other. In this thesis, we use
port-based modeling that captures the behavioral aspects of backloading. Some
backloading problems can be detected even without performing a full behavioral
simulation. For example, a car tire component is compatible with a road component,
but not with a train track component. We address this issue of the functional
compatibility of components through the use of the “intended-use” attribute that provides a
compatibility criterion for interacting component objects. However, more work in
component-to-component functional compatibility and the modeling of “unintended”
interactions is required.
164
Within these constraints, we believe that the composability of VLSI design and tight
integration with CAD tools can be combined with the multi-functional nature of EM design
and its detailed behavioral models. This will provide an environment that will enable
designers to create and test virtual prototypes, and quickly create products that are of
better quality, in shorter time frames.
8.4 A Vision for Simulation-Based Engineered Device Design
Based on the discussion in the previous section, we present a vision for the
simulation-based design of engineered devices. It is assumed that the designer uses the
advances made in this thesis and the enhancements detailed in the previous section.
Consider this scenario: A new EM design project is initiated in a company. The
product is an evolution from an older product. A team of designers is selected, some of
whom have worked on the previous model of the product.
The designers possess a computer database of component objects. They select many
component objects from this database, and create a few new components for the purpose
of the new design. The database is updated with the newly created components.
The designers decompose the top-level function into sub-functions. They assign initial
component objects to each sub-function. The components are connected in a
configuration that represents the EM system. Interaction models are automatically
assigned by the virtual prototyping system.
165
Component behavioral models are selected for each component object. These
component models include multiple behavioral models describing the component from
different perspectives and at different levels of detail, with multiple side effects. As the
designer builds a system from components, the corresponding system-level model is
instantiated from the component models. Depending on the type of the simulation
experiment, the appropriate behavioral models for each of the components and
component interactions are instantiated.
Experiments are run on the virtual prototype to see if it meets the specifications. The
designers realize that some efficiency specifications, like power consumption or total
weight are not met. They decide to make certain component objects multi-functional, and
for this they use their insight gained during the design of the earlier product. Using the
functional modeling capabilities of the system, they combine certain component objects
into a single object that performs multiple functions in the design. This saves weight and
consumes less power.
Upon simulation, undesirable friction and heat related side effects are discovered in
the interaction between two component objects in the system. The designers mitigate this
by redesigning the geometry of a particular component object that incorporates
mechanical and hydraulic models. The tight integration with the mechanical CAD system
and hydraulic CAD system enable the designers to quickly make the necessary changes.
The changes are propagated into the virtual prototyping system. The EM product is now
found to perform to specifications.
166
Finally, a multi-domain finite element solver is coupled with the virtual prototyping
system to perform a very detailed simulation of certain critical component objects in the
product. With this validation of the system-level model, the design team recommends that
the product be manufactured.
8.5 Future Work
In previous sections, we discussed how this thesis forwards the state of the art in EM
design. We also identified important issues at the intersection of EM design and VLSI
design. We elaborate on the research prospects of those issues here. Although a vast
body of work exists in the area of modeling and simulation of engineering systems,
additional research is needed to address the following issues and challenges.
8.5.1 Modeling
Modeling device function at the component level. Simulation languages have evolved
from procedural and functional languages towards equation-based and object-oriented
languages, moving away from the differential equation level towards the use of more
intuitive and user-friendly building blocks. This thesis is a step towards the development of
simulation languages that operate at the level of components and sub-systems.
Functional descriptions of systems are important for achieving efficient designs as well as
for design reuse, an issue that is not addressed in this thesis.
Component interaction modeling in multiple domains. When a designer composes a
system from components, he also defines how these components interact with each other
(their relative positions, electrical contacts, etc.). Currently, the dynamics of these
167
interactions need to be modeled explicitly by the user. However, often the information to
extract these interaction models has already been provided by the designer. The
information needed to determine the interaction models can be automatically obtained
from the domain-specific design tools that are integrated with the modeling environment.
The work done in this thesis should be extended to include support for interaction
modeling in domains other than the mechanics domain.
Selecting an adequate level of detail. At different stages of the design process,
different analyses need to be performed. Correspondingly, the simulation model of a
system needs to be adapted to be adequately accurate without being overly detailed to
avoid wasting computational resources. The current state of the art does not allow
simulation models to be easily converted to different levels of abstraction. Future
research should focus on methods to automatically select the most appropriate model for
each component and component interaction in a system.
Improvement of numerical solvers. Currently, most VHDL-AMS simulators are not
suited for modeling of systems with mechanical components. They often fail to find
algebraically consistent initial conditions and have difficulty solving index-3 problems that
are common in mechanical systems. With the simulation of multi-disciplinary systems
becoming more frequent, solvers need to address the special characteristics posed by all
the different application domains. They should also provide the user with finer control
over the numerical integration, beyond merely selecting the step size and integration
algorithm.
168
8.5.2 Integration with design tools
Integration with CAD. As described in previous sections, close integration between
design tools and the modeling and simulation environment simplifies model creation and
design verification. However, such tight integration has occurred successfully only for
electronic CAD (with some limited integration in other domains). Further integration of
single-domain CAD tools with a common simulation environment is needed so that a team
of designers can create virtual prototypes from within the design environments with which
they are familiar and that are custom-tailored to their needs.
Finite-element modeling. Finite-element tools are currently not integrated with
systems-level modeling environments— partly due to their computational requirements,
partly due to the difficulty interfacing finite element models with lumped models. With the
increases in computational resources, future research should focus these interfacing
issues so that we can include models of distributed physical phenomena like mechanical
flexure, or complex electromagnetic and thermal behavior in system-level models.
8.5.3 Collaborative Modeling
Unified model representation. Recently, several standardization and unification efforts
have resulted in modeling languages and frameworks for simulations in multiple
domains— e.g. Modelica, VHDL-AMS, and HLA. However, most single domain simulation
environments still use proprietary data formats and solvers that are tightly integrated with
the modeling environment. Future modeling and simulation environments should allow for
a tight integration between application domains, either by interfacing the solvers or by
using common model representations.
169
Ontologies for modeling and simulation. To further improve the exchange of model
information (between both agents and humans), researchers have started to develop
domain ontologies [39, 122]. For instance, Ozawa [104] proposed a common ontology to
support different levels of information sharing between humans and multiple modeling and
simulation software agents. Upon these domain ontologies, unified taxonomies and
keyword networks can be built to support model retrieval and repository management.
Libraries of models will help to organize the continuously growing knowledge base
available to EM designers.
170
Appendix A Formalism
A.1 General Definitions
Definition 1: A system consists of component objects and component connections.
Definition 2: A component object O is an entity that completely specifies the component.
Definition 3: A component connection between two component objects specifies the
exchange of energy, mass, or information between the component objects.
Definition 4: Configuration is the act of specifying a system as a set of component
objects connected to each other via component connections.
Definition 5: Denote the configuration operator by °. Let S be the set of component
objects. Then (S, °) is a commutative subgroup, because ° is both
commutative, and closed [78].
Corollary 1: A system is also a component object that can in turn be connected to other
component objects.
Definition 6: Component objects are defined by two layers: the configuration layer and
the modeling layer.
Definition 7: The configuration layer specifies the instantiation and connectivity
information for the component objects. It contains the configurations that
represent this component object.
Definition 8: A behavioral model is a mathematical model that describes the physical
and informational behavior of the component object.
171
Definition 9: A CAD model is a description of the geometry and bill of materials for the
component object.
Definition 10: The modeling layer specifies the CAD and behavioral information for
component objects and component connections. It contains the CAD and
behavioral models.
Theorem 1: The separation theorem in ZF [64, 135] applied to simulation-based design
can be stated as: for any design entity D (or set of entities D), and any
predicate ϕ, there is an entity E that is a subset of D that contains only
members of D that satisfy ϕ:
( ) ( ) ( ) ( ) ( )( )( )E x x E x D xϕ ∃ ∀ ∈ → ∈ ∧ (A.1)
A.2 Ports
Definition 11: A port p is a logical, discrete point at which an interaction between a
component object and its environment occurs, either in the configuration or
in the modeling layer.
Definition 12: A configuration port is used to connect component objects.
Definition 13: A modeling port is used to connect behavioral models.
Definition 14: An instantiation parameter is a parameter provided to a component object
in the configuration layer, so that it can be instantiated in a configuration.
Definition 15: A model parameter is a parameter provided to a behavioral model of a
component object, so that the model can be evaluated.
Definition 16: The configuration ports and instantiation parameters of a component object
are collectively known as the configuration interface.
172
Definition 17: The modeling ports and modeling parameters of a behavioral model are
collectively known as the modeling interface.
Axiom 1: All interactions are through ports. (Universality Axiom)
Axiom 2: The ports in the interface are ordered (Uniqueness Axiom)
Definition 18: An attribute is a unique, discrete property of a port (or component object or
behavioral model) that can be assigned a value with some associated
semantics.
Axiom 3: All attributes are independent of each other (Orthogonality Axiom)
Definition 19: A primitive port describes an interaction that cannot be described as an
aggregation of other interactions. Therefore a primitive port cannot be
modeled as an aggregation of other ports. There exist both primitive
configuration ports and primitive modeling ports.
Axiom 4: A port is modeled as a finite set of unique, identifiable attribute-value pairs.
These attributes can be ports (Finiteness Axiom)
Axiom 5: Every configuration port type has at least one compatible port type
(Compatibility Axiom)
Definition 20: The compatible type of modeling energy port types and the modeling
INOUT signal port type is the original type. The complementary type of the
modeling IN signal type is the modeling OUT signal type and vice versa.
Axiom 6: If the set of attributes of two ports are identical, then the two ports are
identical (Identity Axiom)
173
Axiom 7: Every primitive port has a location attribute specifying the portion of the
interface that participates in the interaction. This can be a point or a region.
The location is modeled as a CAD feature (Location Axiom).
Axiom 8: Every primitive port has a material attribute specifying the material at the
port location. The material specification includes the material name and
properties (Material Axiom).
Axiom 9: Every port has an intended use attribute specifying the function that this
port is meant to perform (Intended Use Axiom).
Axiom 10: For a given type T, if there exists a set of types U such that T contains all
the attributes of all the members of U, then T is said to inherit from the
members of U, and T is a specialized type of the types in U. (Port
Specialization Axiom)
( ) ( ) ( )( )( ) T U x x U x T U T ∀ ∃ ∀ ∈ → ∈ ∧ ⊂ (A.2)
Proof: Restatement of Theorem 1 with D=T and E=U.
Axiom 11: If all the members of a set of types U have in common some attributes,
then a general type T can be defined containing those common attributes
and type T is a generalized type of the types in U. (Port Generalization
Axiom).
( ) ( ) ( )( ) U T x x T x A y y U x y ∀ ∃ ∀ ∈ → ∈ ∧ ∀ ∈ ∧ ∈ (A.3)
Proof: Restatement of Theorem 1.
Definition 21: IS_A() is a predicate that is satisfied by a port P and a type T iff P is of type
T (Typing Predicate).
174
Definition 22: SUBTYPE_OF() is a predicate that is satisfied by two port types p and q iff
p is a specialization of Q (Specialization Predicate):
Definition 23: GENERALIZATION_OF() is a predicate that is satisfied by two ports P and
Q iff Q is a subtype of P (Generalization Predicate).
( ) ( )_ , _ ,SUBTYPE OF P Q GENERALIZATION OF Q P→ (A.4)
Both SUBTYPE_OF() and GENERALIZATION_OF() predicates are
reflexive and transitive.
A.3 Component Interaction Models
Definition 24: An interaction model is a relation over a collection of sets of ports A, B, C,
... resulting in a set of ordered sequences <a,b,c,...> such that a ∈ A, b ∈
B, etc.
Definition 25: A connection is a 3-tuple <o1(pa), o2(pb), M> that relates port pa on one
component object o1 to port pb on another component object o2 via
interaction model M.
Axiom 12: A connection can only be made between 2 ports of compatible types
(Connectivity Axiom).
Axiom 13: If an interaction model M has a port that can be generalized to the
MASS/ENERGY port, then it must have at least another port that can be
generalized to the MASS/ENERGY port (Mass-Energy Conservation
Axiom):
175
( ) ( )( )( ) ( ) ( )( )
_ , /
_ , /
P P M GENERALIZATION OF P MASS ENERGY
P P M GENERALIZATION OF P MASS ENERGY P P
∃ ∈ →′ ′ ′ ′∃ ∈ ∧ ≠
(A.5)
Theorem 2: An interaction model M defined with a set of ports <a,b,c,...> can be
replaced by another interaction model M' defined with a set of ports
<a',b',c',...> where SUBTYPE_OF(a,a'), SUBTYPE_OF(b,b'),
SUBTYPE_OF(c,c'), etc. (Model Subtyping Theorem)
Definition 26: REPLACE() is a predicate that is satisfied by two interaction models M and
N iff M can be replaced by N (Model Reconfiguration Predicate)
Corollary 2: REPLACE() is reflexive and transitive.
176
Appendix B XML Representation for a
Train-Track Port
B.1 Partial Port DTD
<?xml version="1.0" encoding="UTF-8"?> <!-- The top-level index that enumerates all the main categories of ports --> <!ELEMENT index (train-ports, powerdrill-ports)> <!ELEMENT train-ports (port*)> <!ELEMENT powerdrill-ports (port*)> <!-- ************************** P O R T ************************* A port defines a particular interaction between a component and its environment. --> <!ELEMENT port (location, material, intended-use, other-port-attribute*)> <!ATTLIST port name NMTOKEN #REQUIRED description CDATA #REQUIRED > <!-- ************************** L O C A T I O N ************************* A location defines a particular physical point where the port is located on the component. --> <!ELEMENT location EMPTY> <!ATTLIST location name NMTOKEN #REQUIRED cad-model CDATA #REQUIRED > <!-- ************************** M A T E R I A L ************************* A material defines a particular material. It describes the properties of the material using a container. It also has a type identifier and a description string. --> <!ELEMENT material (property-list)> <!ATTLIST material name NMTOKEN #REQUIRED description CDATA #REQUIRED > <!-- *********************** I N T E N D E D - U S E ********************** The intended-use attribute defines the functions that this port performs using a container. --> <!ELEMENT intended-use (function-list)> <!-- ************** O T H E R - P O R T - A T T R I B U T E *************
177
The other-port-attribute attribute is just a collection of other optional attributes that the designer may choose to include. --> <!ELEMENT other-port-attribute EMPTY> <!-- **************** F U N C T I O N - L I S T **************** function-list is a list of intended uses. IMPORTANT!: When you add a new functionto the DTD, remember to add the tag name to the function-list as well!! --> <!ELEMENT function-list (roll-on-surface?, provide-rolling-surface?, transmit-electrical-power?)> <!-- ****************** E N E R G Y - D O M A I N ****************** An energy-domain attribute describes the energy domains that the port participates in. --> <!ELEMENT energy-domain EMPTY> <!ATTLIST energy-domain name (electrical | mechanical | thermal | fluidic | signal | software) #REQUIRED > <!-- ************************ F U N C T I O N ************************ A function attribute describes a particular function of the port. Each function has its own tag. Each function also has a compatible function tag that designates any compatible functions. --> <!ELEMENT roll-on-surface (energy-domain+)> <!ATTLIST roll-on-surface name CDATA #FIXED "Roll on surface" description CDATA #FIXED "This provides a rolling surface such as that on a tire" > <!ELEMENT provide-rolling-surface (energy-domain+)> <!ATTLIST provide-rolling-surface name CDATA #FIXED "Provide a flat surface" description CDATA #FIXED "This provides a flat surface such as a road" > <!ELEMENT transmit-electrical-power (energy-domain+)> <!ATTLIST transmit-electrical-power name CDATA #FIXED "transmit electrical power" description CDATA #FIXED "transmit electrical power through a physical contact" constraints CDATA #IMPLIED > <!-- ************************ M A T E R I A L - R E F ************************ A material reference is a pointer to a material. --> <!ELEMENT material-ref EMPTY> <!ATTLIST material-ref name NMTOKEN #REQUIRED > <!-- **************** P R O P E R T Y - L I S T **************** property-list is a list of material properties. IMPORTANT!: When you add a new material property to the DTD, remember to add the tag name to the property list as well!! --> <!ELEMENT property-list (Volume-Density?, Youngs-Modulus?, Poisson-Ratio?, Resistivity?)> <!-- ************************ P R O P E R T Y ************************ A property attribute describes a particular property of the material. Each property has its own tag.
178
--> <!-- Inertial properties --> <!ELEMENT Volume-Density EMPTY> <!ATTLIST Volume-Density name CDATA #FIXED "Volume Density" definition CDATA #FIXED "The measure of the mass of matter that occupies a unit volume." symbol NMTOKEN #FIXED "rho" units CDATA #FIXED "kg/m^3" typical-values CDATA #FIXED "wide range" equation CDATA #FIXED "rho = m/V" restrictions CDATA #FIXED "at 273.16K" value CDATA #REQUIRED > <!-- Stress-strain properties --> <!ELEMENT Youngs-Modulus EMPTY> <!ATTLIST Youngs-Modulus name CDATA #FIXED "Youngs Modulus" definition CDATA #FIXED "A proportionality constant that determines the relative length change (longitudinal strain) of a solid bar, when a uniform stress is applied." symbol NMTOKEN #FIXED "E" units CDATA #FIXED "N/m^2" typical-values CDATA #FIXED "1e4 - 1e6" equation CDATA #FIXED "Stress = E * dL/L" restrictions CDATA #FIXED "solids only" value CDATA #REQUIRED > <!ELEMENT Poisson-Ratio EMPTY> <!ATTLIST Poisson-Ratio name CDATA #FIXED "Poisson Ratio" definition CDATA #FIXED "When a bar is in longitudinal strain it also tends to change its dimensions in the direction perpendicular to the applied stress. The dimensionless ratio between the relative length change along the two perpendicular directions is called the Poisson ratio." symbol NMTOKEN #FIXED "sigma" units CDATA #FIXED "no units" typical-values CDATA #FIXED "0.3 - 0.5" equation CDATA #FIXED "dW/W = sigma dL/L" restrictions CDATA #FIXED "solids only" value CDATA #REQUIRED > <!-- Electrical properties --> <!ELEMENT Resistivity EMPTY> <!ATTLIST Resistivity name CDATA #FIXED "Resistivity" definition CDATA #FIXED "The measure electrical resistance of a material." symbol NMTOKEN #FIXED "rho" units CDATA #FIXED "ohm-meter" typical-values CDATA #FIXED "none" equation CDATA #FIXED "rho = RA/L" restrictions CDATA #FIXED "at 273.16K" value CDATA #REQUIRED >
179
B.2 Port XML Document
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE index SYSTEM "C:\Raj\docs\attrmodels\port.dtd"> <index> <train-ports> <port name="wheel-port" description="Wheel port on a train"> <location name="running-surface" cad-model="cylindrical-feature"></location> <material name="vulcanized-rubber" description="Tire rubber"> <property-list><Volume-Density value="3000"/></property-list> </material> <intended-use> <function-list><roll-on-surface><energy-domain name="mechanical"/> </roll-on-surface></function-list> </intended-use> </port> <port name="brush-port" description="Brush port on central pylon"> <location name="brushes" cad-model="brush-feature"></location> <material name="steel" description="Steel"> <property-list><Volume-Density value="7700"/> <Resistivity value="2000"/></property-list> </material> <intended-use> <function-list><transmit-electrical-power><energy-domain name="electrical"/> </transmit-electrical-power></function-list> </intended-use> </port> </train-ports> <powerdrill-ports/> </index>
180
Appendix C Modelica Models
C.1 MEMS Connector
connector MEMSConnector // this is a 2D MEMS (mechanical) connector input Modelica.SIunits.Position r0[2]
"Position vector from 2D inertial system to connector origin, resolved in inertial system";
Modelica.SIunits.Angle S "Angle from connector to inertial system"; Modelica.SIunits.Velocity v[2] "Absolute velocity of frame origin, resolved in connector"; Modelica.SIunits.AngularVelocity w "Absolute angular velocity of connector, resolved in connector"; Modelica.SIunits.Acceleration a[2] "Absolute acceleration of frame origin, resolved in connector"; Modelica.SIunits.AngularAcceleration z "Absolute angular acceleration of connector, resolved in connector"; flow Modelica.SIunits.Force f[2]; flow Modelica.SIunits.Torque t; end MEMSConnector
C.2 Base Classes
C.2.1 OneMEMSConnector Model
partial model OneMEMSConnector protected Modelica.SIunits.Angle Sa "angular position"; Modelica.SIunits.Position r0a[2] "position in m"; Modelica.SIunits.Velocity va[2] "linear velocity in m/s"; Modelica.SIunits.AngularVelocity wa "angular velocity in rad/s"; Modelica.SIunits.Acceleration aa[2] "linear acceleration in m/s^2";
181
Modelica.SIunits.AngularAcceleration za "angular acceleration in rad/s^2"; Modelica.SIunits.Force fa[2] "force in N"; Modelica.SIunits.Torque ta "torque in Nm"; public CompSim.MEMS.Interfaces.MEMSConnector memsC( S=Sa, r0=r0a, v=va, w=wa, a=aa, z=za, f=fa, t=ta); end OneMEMSConnector
C.2.2 TwoMEMSConnectors Model
partial model TwoMEMSConnectors "Superclass of MEMS elements with TWO MEMS connectors" protected Modelica.SIunits.Angle Sa; Modelica.SIunits.Position r0a[2]; Modelica.SIunits.Velocity va[2]; Modelica.SIunits.AngularVelocity wa; Modelica.SIunits.Acceleration aa[2]; Modelica.SIunits.AngularAcceleration za; Modelica.SIunits.Force fa[2]; Modelica.SIunits.Torque ta; Modelica.SIunits.Angle Sb; Modelica.SIunits.Position r0b[2]; Modelica.SIunits.Velocity vb[2]; Modelica.SIunits.AngularVelocity wb; Modelica.SIunits.Acceleration ab[2]; Modelica.SIunits.AngularAcceleration zb; Modelica.SIunits.Force fb[2]; Modelica.SIunits.Torque tb; public MEMSConnector MEMSConnector1( S=Sa, r0=r0a, v=va, w=wa, a=aa, z=za, f=fa, t=ta);
182
MEMSConnector MEMSConnector2( S=Sb, r0=r0b, v=vb, w=wb, a=ab, z=zb, f=fb, t=tb); equation end TwoMEMSConnectors
C.3 Component Objects
C.3.1 MEMSInertialSystem Model
model MEMSInertialSystem parameter String label1="x" "Label of horizontal axis in icon"; parameter String label2="y" "Label of vertical axis in icon"; parameter Modelica.SIunits.Acceleration accel_source[2]=0,0 "acceleration vector"; parameter Modelica.SIunits.AngularVelocity angvel_source=0 "angular velocity"; parameter Modelica.SIunits.AngularAcceleration angaccel_source=0 "angular acceleration"; MEMSConnector MEMSConnector1; equation /*Equations*/ MEMSConnector1.S = 0; MEMSConnector1.r0 = zeros(2); MEMSConnector1.v = zeros(2); MEMSConnector1.w = angvel_source; MEMSConnector1.a = accel_source; MEMSConnector1.z = angaccel_source; end MEMSInertialSystem
C.3.2 Generic Mass Model
model MassBase extends Interfaces.OneMEMSConnector; parameter Modelica.SIunits.Mass m=0 "Mass of body [kg]"; parameter Modelica.SIunits.MomentOfInertia I=0 "inertia"; parameter Real damping_x=0 "damping coefficient in x"; parameter Real damping_y=0 "damping coefficient in y"; parameter Modelica.SIunits.Length damping_length=1
183
"length of moment arm for rotational damping"; parameter Modelica.SIunits.Length shape_length=0 "length of display shape"; parameter Modelica.SIunits.Length shape_width=0 "width of display shape"; // define aliases for needed packages protected package MEMS_Constants = CompSim.MEMS.MEMS_Constants; parameter Modelica.SIunits.Length height=MEMS_Constants.air_gap + MEMS_Constants.poly1_t/2; public ModelicaAdditions.MultiBody.Parts.Shape SE( r0=-shape_length/2,0,0, Length=shape_length, Width=shape_width, Height=MEMS_Constants.poly1_t, Material=0,1,0,0.5); equation // Assumption: va is relative to the substrate fa = m*aa + damping_x*va[1],damping_y*va[2]; ta = I*za + damping_x*damping_length*wa; SE.frame_a.r0 = r0a[1],r0a[2],height; SE.frame_a.v = va[1],va[2],0; SE.frame_a.a = aa[1],aa[2],0; SE.frame_a.S = cos(Sa),-sin(Sa),0,sin(Sa),cos(Sa),0,0,0,1; SE.frame_a.w = 0,0,wa; SE.frame_a.z = 0,0,za; end MassBase
C.3.3 Generic Spring Model
model MEMSSpring extends Interfaces.TwoMEMSConnectors; public parameter Real k[3, 3]=identity(3) "stiffness matrix"; // relative kinematic variables protected Modelica.SIunits.Angle S_rel; Modelica.SIunits.Position r_rela[2]; Modelica.SIunits.Velocity v_rela[2]; Modelica.SIunits.AngularVelocity w_rela; Modelica.SIunits.Acceleration a_rela[2];
184
Modelica.SIunits.AngularAcceleration z_rela; // relative dynamic variables Modelica.SIunits.Force f_rel[2]; Modelica.SIunits.Torque t_rel; Modelica.SIunits.Velocity vx; Modelica.SIunits.Velocity vy; Modelica.SIunits.Velocity vaux[2]; equation // relate both frames Sb - Sa = S_rel; r0b = r0a + cos(Sa),-sin(Sa),sin(Sa),cos(Sa)*r_rela; vaux = wa*-r_rela[2],r_rela[1]; vb = cos(S_rel),-sin(S_rel),sin(S_rel),cos(S_rel)*(va + v_rela + vaux) ; wb = wa + w_rela; ab = cos(S_rel),-sin(S_rel),sin(S_rel),cos(S_rel)*(aa + a_rela + za*- r_rela[2],r_rela[1] + wa*-(wa*r_rela[1] + 2*vy),-wa*r_rela[2] + 2*vx); zb = za + z_rela; f_rel = fb - fa; t_rel = tb - ta; f_rel[1],f_rel[2],t_rel = k*r_rela[1],r_rela[2],S_rel; end MEMSSpring
C.3.4 Generic Damper Model
model MEMSDamper extends Interfaces.TwoMEMSConnectors; public parameter Real b[3, 3]=identity(3) "damping matrix"; // relative kinematic variables protected Modelica.SIunits.Angle S_rel; Modelica.SIunits.Position r_rela[2]; Modelica.SIunits.Velocity v_rela[2]; Modelica.SIunits.AngularVelocity w_rela; Modelica.SIunits.Acceleration a_rela[2]; Modelica.SIunits.AngularAcceleration z_rela; // relative dynamic variables Modelica.SIunits.Force f_rel[2];
185
Modelica.SIunits.Torque t_rel; equation // relate both frames Sb - Sa = S_rel; r0b = r0a + cos(Sa),-sin(Sa),sin(Sa),cos(Sa)*r_rela; vaux = wa*-r_rela[2],r_rela[1]; vb = cos(S_rel),-sin(S_rel),sin(S_rel),cos(S_rel)*(va + v_rela + vaux) ; wb = wa + w_rela; ab = cos(S_rel),-sin(S_rel),sin(S_rel),cos(S_rel)*(aa + a_rela + za*- r_rela[2],r_rela[1] + wa*-(wa*r_rela[1] + 2*vy),-wa*r_rela[2] + 2*vx); zb = za + z_rela; f_rel = fb - fa; t_rel = tb - ta; f_rel[1],f_rel[2],t_rel = b*r_rela[1],r_rela[2],S_rel; end MEMSDamper
C.3.5 Resistor Model (from Modelica Electrical Library)
model Resistor "Ideal linear electrical resistor" extends Modelica.Electrical.Analog.Interfaces.OnePort; parameter SIunits.Resistance R=1 "Resistance"; equation R*i = v; end Resistor
C.3.6 Electrical Ground Model (from Modelica Electrical Library)
model Ground "Ground node" Modelica.Electrical.Analog.Interfaces.Pin p; equation p.v = 0; end Ground
C.3.7 Anchor Model
model Anchor parameter Modelica.SIunits.Position r[2]=0,0 "Vector from frame_a to frame_b resolved in frame_a"; parameter Real angle=0 "angular position of anchor in degrees"; protected package Constants = Modelica.Constants;
186
Modelica.SIunits.Velocity vaux[2]; parameter Modelica.SIunits.Angle S_rel=angle*Constants.pi/180 "angle in radians"; parameter Real Rot[2, 2]=cos(S_rel),sin(S_rel),-sin(S_rel),cos(S_rel) "relative transformation matrix of frame_a wrt frame_b"; public CompSim.MEMS.Interfaces.MEMSConnector frame_a; CompSim.MEMS.Interfaces.MEMSConnector frame_b; equation /* Assumptions a_rela = 0 v_rela = 0 Rot_a = identity Sa = 0 roa = 0 */ frame_b.S = S_rel; frame_b.w = frame_a.w; frame_b.z = frame_a.z; frame_b.r0 = r; vaux = frame_a.w*-r[2],r[1]; frame_b.v = Rot*(frame_a.v + vaux); frame_b.a = Rot*(frame_a.a + frame_a.z*-r[2],r[1] + frame_a.w*-vaux[2], vaux[1]); /*Transform the force and torque acting at frame_b to frame_a*/ frame_a.f + transpose(Rot)*frame_b.f = 0,0; frame_a.t + frame_b.t - r[1]*frame_a.f[2] + r[2]*frame_a.f[1] = 0; end Anchor
C.3.8 Cut Anchor Model
model CutAnchor extends Interfaces.TwoMEMSConnectors; parameter Modelica.SIunits.Position r[2]=0,0 "Vector from frame_a to frame_b resolved in frame_a"; parameter Real angle=0 "angular position of anchor in degrees"; protected package Constants = Modelica.Constants; Modelica.SIunits.Velocity vaux[2]; parameter Modelica.SIunits.Angle S_rel=angle*Constants.pi/180
187
"angle in radians"; parameter Real Rot[2, 2]=cos(S_rel),sin(S_rel),-sin(S_rel),cos(S_rel) "relative transformation matrix of frame_a wrt frame_b"; Modelica.SIunits.Angle Sresidue; Modelica.SIunits.Position r_rela[2]; Modelica.SIunits.Velocity v_rela[2]; Modelica.SIunits.AngularVelocity w_rela; Modelica.SIunits.Acceleration a_rela[2]; Modelica.SIunits.AngularAcceleration z_rela; Real constraintResidue[3]; Real constraintResidue_d[3]; Real constraintResidue_dd[3]; equation /*relative positions*/ r_rela = r0b - r; Sresidue = Sb - S_rel; /*relative velocities*/ vaux = wa*-r[2],r[1]; // vb = Rot*(va + vaux + v_rela); v_rela = transpose(Rot)*vb - va - vaux; w_rela = wb - wa; /*relative accelerations*/ ab = Rot*(aa + a_rela + za*-r_rela[2],r_rela[1] + wa*-(wa*r_rela[1] + 2* v_rela[2]),-wa*r_rela[2] + 2*v_rela[1]); z_rela = zb - za; /*Transform the force and torque acting at frame_b to frame_a*/ fa + transpose(Rot)*fb = 0,0; ta + tb - r[1]*fa[2] + r[2]*fa[1] = 0; /*Constraint equations on position, velocity and acceleration level*/ constraintResidue = r_rela[1],r_rela[2],Sresidue; constraintResidue_d = v_rela[1],v_rela[2],w_rela; constraintResidue_dd = a_rela[1],a_rela[2],z_rela; constrain(constraintResidue, constraintResidue_d, constraintResidue_dd); end CutAnchor
188
C.3.9 Beam Stiffness Model
model Beam_YTheta extends Interfaces.TwoMEMSConnectors; // the parameters public parameter Modelica.SIunits.Distance l=100e-6 "length in m"; parameter Modelica.SIunits.Distance w=2e-6 "width in m"; // port definitions protected Modelica.SIunits.Voltage v "Voltage drop between the two electrical ports (= p.v - n.v)"; Modelica.SIunits.Current i "Current flowing from one electrical port to another"; // relative kinematic variables Modelica.SIunits.Angle S_rel; Modelica.SIunits.Position r_rela[2]; Modelica.SIunits.Velocity v_rela[2]; Modelica.SIunits.AngularVelocity w_rela; Modelica.SIunits.Acceleration a_rela[2]; Modelica.SIunits.AngularAcceleration z_rela; // define aliases for needed packages package MEMS_Constants = CompSim.MEMS.MEMS_Constants; package Constants = Modelica.Constants; // state variables Modelica.SIunits.Position y; Real disp[2] "generalized displacement "; Real vel[2] "generalized velocity"; Real Rot[2, 2]; Real Rot_a[2, 2]; // auxiliary variables parameter Modelica.SIunits.Resistance R=MEMS_Constants.poly1_rho*(l/w) "resistance through beam"; parameter Modelica.SIunits.SecondMomentOfArea ii=MEMS_Constants.poly1_t*(w*w *w)/12 "geometric moment of inertia about z-axis"; // stiffness force
189
Real Fs[2] "generalized stiffness force in the beam coordinates"; // total force in beam coordinates Real F[2] "generalized total force in the beam coordinates"; // coefficients for spring and effective mass parameter Real c12=12*MEMS_Constants.E*ii/(l*l*l); parameter Real c6=6*MEMS_Constants.E*ii/(l*l); parameter Real c4=4*MEMS_Constants.E*ii/l; // stiffness matrix parameter Real K[2, 2]=c12,-c6,-c6,c4 "Stiffness matrix"; public Modelica.Electrical.Analog.Interfaces.PositivePin PositivePin1; Modelica.Electrical.Analog.Interfaces.NegativePin NegativePin1; equation v = PositivePin1.v - NegativePin1.v; 0 = PositivePin1.i + NegativePin1.i; i = PositivePin1.i; // Ohm's law R*i = v; // state // S_rel is also part of the state r_rela = l,y; // derivatives of state w_rela = der(S_rel); z_rela = der(w_rela); v_rela = der(r_rela); a_rela = der(v_rela); // The "Rot" transform is the angular position of frame A wrt frame B. Rot = cos(S_rel),sin(S_rel),-sin(S_rel),cos(S_rel); Rot_a = cos(Sa),-sin(Sa),sin(Sa),cos(Sa); // relate both frames (Sb - Sa) = S_rel; r0b = r0a + Rot_a*r_rela; vb = Rot*(va + v_rela + wa*-r_rela[2],r_rela[1]); wb = wa + w_rela; ab = Rot*(aa + a_rela + za*-r_rela[2],r_rela[1] + wa*-(wa*r_rela[1] + 2* v_rela[2]),-wa*r_rela[2] + 2*v_rela[1]);
190
zb = za + z_rela; // generalized state disp = r_rela[2],S_rel; vel = v_rela[2],w_rela; /*Transform the force and torque acting at frame_b to frame_a*/ // forces act on the beam, so they sum to zero (no inertia). fa + transpose(Rot)*fb = 0,0; ta + tb - r_rela[1]*fa[2] + r_rela[2]*fa[1] = 0; // compute stiffness force Fs = K*disp; // compute total force F = Fs; // relate total force to frame variables F = fb[2],tb; end Beam_YTheta
C.3.10 Beam Model
model BeamElement // the parameters public parameter Modelica.SIunits.Distance l=100e-6 "length in m"; parameter Modelica.SIunits.Distance w=2e-6 "width in m"; protected parameter Modelica.SIunits.Mass ms=MEMS_Constants.poly1_den*w*l* MEMS_Constants.poly1_t "mass of beam"; parameter Modelica.SIunits.MomentOfInertia ii=ms*(l*l + w*w)/12 "mass moment of inertia about z-axis"; public Interfaces.MEMSConnector MEMSConnector1; Interfaces.MEMSConnector MEMSConnector2; Modelica.Electrical.Analog.Interfaces.PositivePin PositivePin1; Modelica.Electrical.Analog.Interfaces.NegativePin NegativePin1; Beam_YTheta Beam_YTheta1(l=l/2, w=w); Beam_YTheta Beam_YTheta2(l=l/2, w=w); MassBase MassBase1( m=ms, I=ii, damping_x=MEMS_Constants.visc_air*l*(w + 4e-6)/MEMS_Constants.air_gap, damping_y=MEMS_Constants.visc_air*(l + 4e-6)*w/MEMS_Constants.air_gap, damping_length=l/2,
191
shape_length=l, shape_width=w); equation connect(Beam_YTheta1.PositivePin1, PositivePin1); connect(Beam_YTheta2.NegativePin1, NegativePin1); connect(Beam_YTheta2.PositivePin1, Beam_YTheta1.NegativePin1); connect(MEMSConnector1, Beam_YTheta1.MEMSConnector1); connect(Beam_YTheta1.MEMSConnector2, Beam_YTheta2.MEMSConnector1); connect(Beam_YTheta2.MEMSConnector2, MEMSConnector2); connect(MassBase1.memsC, Beam_YTheta1.MEMSConnector2); end BeamElement
C.3.11 Comb Mass Model
model CombMass // parameters public parameter Modelica.SIunits.Length finger_width=2e-6 "width of a finger"; parameter Modelica.SIunits.Length finger_length=10e-6 "length of a finger"; parameter Modelica.SIunits.Length overlap=5e-6 "overlap between fingers"; parameter Modelica.SIunits.Distance gap=2e-6 "gap between fingers"; parameter Modelica.SIunits.Length thickness=2e-6 "thickness of a finger"; parameter Integer fingers=3 "number of fingers"; parameter Modelica.SIunits.Length wing_length=0; parameter Modelica.SIunits.Length truss_width=0; // Parameter number is added to the fingers for the // purpose of computing the mass and the damping // This is needed because we cannot pass fingers+1 // as the parameter parameter Real number=1; parameter Modelica.SIunits.Density density=MEMS_Constants.poly1_den; // 2330 // define aliases for needed packages protected package MEMS_Constants = CompSim.MEMS.MEMS_Constants; package Constants = Modelica.Constants; // internal variables parameter Modelica.SIunits.Mass ms=((fingers + number)*finger_length*
192
finger_width + (trusslength*truss_width))*thickness*density; parameter Modelica.SIunits.Length trusslength=2*wing_length + (fingers + number)*finger_width + (fingers + number - 1)*finger_width + 2*(fingers + number - 1)*gap; parameter Modelica.SIunits.Area r_square=computeRsq(fingers, finger_width, gap); parameter Modelica.SIunits.Mass mass_finger=finger_length*finger_width* thickness*density; // moment of inertia parameter Modelica.SIunits.Inertia ii1=(r_square + fingers*((truss_width + finger_length - overlap/2)^2))*mass_finger; // Contribution of the fingers and the truss to MI parameter Modelica.SIunits.Inertia ii2=fingers*mass_finger*((finger_length* finger_length + finger_width*finger_width)/12) + (trusslength*truss_width *thickness*density)*((trusslength^2)/12 + (truss_width^2)/3); parameter Modelica.SIunits.Inertia ii=ii1 + ii2; // center of mass Modelica.SIunits.Length center_mass_x=0; Modelica.SIunits.Length center_mass_y=0; // function to compute the r-squared function computeRsq input Real fingers; input Modelica.SIunits.Length finger_width; input Modelica.SIunits.Distance gap; output Real r_square=0.0; protected Modelica.SIunits.Distance dis_y; algorithm for i in 1:(fingers/2) loop // Two cases for dis_y, fingers is odd or fingers is even // Y Distance of the center of the finger from the center of the // comb-drive dis_y := rem(fingers, 2)*i*(gap + finger_width) + rem(fingers + 1, 2)*(i *(gap + finger_width) - 0.5*(gap + finger_width));
193
r_square := r_square + 2*(dis_y^2); end for; end computeRsq; public Interfaces.MEMSConnector MEMSConnector1; MassBase MassBase1( m=ms, I=ii, shape_length=finger_length + truss_width, shape_width=(finger_width + gap)*2*(fingers + 1) - gap); equation connect(MEMSConnector1, MassBase1.memsC); end CombMass
C.3.12 Comb Drive Model
model ElectrostaticPlateDrive // the parameters public parameter Modelica.SIunits.Distance finger_width=2e-6 "width of fingers in m"; parameter Modelica.SIunits.Distance finger_length=10e-6 "length of fingers in m"; parameter Modelica.SIunits.Length thickness=MEMS_Constants.poly1_t "thickness of a finger in m"; parameter Modelica.SIunits.Distance overlap=5e-6 "finger overlap in m"; parameter Modelica.SIunits.Distance gap=2e-6 "gap between fingers in m"; parameter Integer fingers=3 "number of fingers"; parameter Real fringe_factor=0 "fraction increase in capacitance due to fringing effects"; parameter Modelica.SIunits.Position Xc=0 "x-position in m"; parameter Modelica.SIunits.Position Yc=0 "y-position in m"; parameter Modelica.SIunits.Distance wing_length_a=0 "wing length at end 1 in m"; parameter Modelica.SIunits.Distance wing_length_b=0 "wing length at end 2 in m"; parameter Modelica.SIunits.Distance truss_width_a=0 "truss width at end 1 in m"; parameter Modelica.SIunits.Distance truss_width_b=0 "truss width at end 2 in m"; Interfaces.MEMSConnector MEMSConnector1; Interfaces.MEMSConnector MEMSConnector2; CombMass CombMass1(
194
finger_width=finger_width, finger_length=finger_length, overlap=overlap, gap=gap, thickness=thickness, fingers=fingers, wing_length=wing_length_a, truss_width=truss_width_a, number=1); CombMass CombMass2( finger_width=finger_width, finger_length=finger_length, overlap=overlap, gap=gap, thickness=thickness, fingers=fingers, wing_length=wing_length_b, truss_width=truss_width_b, number=0); Modelica.Electrical.Analog.Interfaces.PositivePin PositivePin1; Modelica.Electrical.Analog.Interfaces.NegativePin NegativePin1; Interactions.Electrostatic_ParallelPlate Electrostatic_ParallelPlate1( finger_width=finger_width, overlap=overlap, gap=gap, fingers=fingers, fringe_factor=fringe_factor); equation connect(CombMass2.MEMSConnector1, MEMSConnector2); connect(CombMass1.MEMSConnector1, MEMSConnector1); connect(Electrostatic_ParallelPlate1.MEMSConnector1, MEMSConnector1); connect(Electrostatic_ParallelPlate1.MEMSConnector2, MEMSConnector2); connect(Electrostatic_ParallelPlate1.NegativePin1, PositivePin1); connect(Electrostatic_ParallelPlate1.PositivePin1, NegativePin1); end ElectrostaticPlateDrive
C.3.13 Rigid Plate Model
model PlateElement_Oriented // the parameters public parameter Modelica.SIunits.Length l=10e-6 "length per plate unit in m";
195
parameter Modelica.SIunits.Length w=10e-6 "width per plate unit in m"; parameter Real fraction_holes=0 "fraction of holes in the plate (>=0, <=1)"; parameter Modelica.SIunits.Length offset=0 "offest for the beam-plate joint" ; public Interfaces.MEMSConnector mems1; Modelica.Electrical.Analog.Interfaces.Pin p1; Interfaces.MEMSConnector mems2; Modelica.Electrical.Analog.Interfaces.Pin p2; Interfaces.MEMSConnector mems3; Modelica.Electrical.Analog.Interfaces.Pin p3; Interfaces.MEMSConnector mems4; Modelica.Electrical.Analog.Interfaces.Pin p4; Interfaces.MEMSConnector mems5; Modelica.Electrical.Analog.Interfaces.Pin p5; Interfaces.MEMSConnector mems6; Modelica.Electrical.Analog.Interfaces.Pin p6; Interfaces.MEMSConnector mems7; Modelica.Electrical.Analog.Interfaces.Pin p7; Interfaces.MEMSConnector mems8; Modelica.Electrical.Analog.Interfaces.Pin p8; Interfaces.MEMSConnector mems9; Modelica.Electrical.Analog.Interfaces.Pin p9; Interfaces.MEMSConnector mems10; Modelica.Electrical.Analog.Interfaces.Pin p10; Interfaces.MEMSConnector mems11; Modelica.Electrical.Analog.Interfaces.Pin p11; Interfaces.MEMSConnector mems12; Modelica.Electrical.Analog.Interfaces.Pin p12; Modelica.Electrical.Analog.Basic.Resistor Resistor1(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Interfaces.Pin Pin1; Modelica.Electrical.Analog.Basic.Resistor Resistor2(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor3(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor4(R=MEMS_Constants. poly1_rho*(l/w));
196
Modelica.Electrical.Analog.Basic.Resistor Resistor5(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor6(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor7(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor8(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor9(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor10(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor11(R=MEMS_Constants. poly1_rho*(l/w)); Modelica.Electrical.Analog.Basic.Resistor Resistor12(R=MEMS_Constants. poly1_rho*(l/w)); MassBase MassBase1( m=MEMS_Constants.poly1_den*w*l*MEMS_Constants.poly1_t*(1 - fraction_holes) , I=MEMS_Constants.poly1_den*w*l*MEMS_Constants.poly1_t*(l*l + w*w)/12*(1 - fraction_holes), damping_x=MEMS_Constants.visc_air*(l*(w + 4e-6))/MEMS_Constants.air_gap, damping_y=MEMS_Constants.visc_air*((l + 4e-6)*w)/MEMS_Constants.air_gap, damping_length=(l + w)/2, shape_length=l, shape_width=w); Interfaces.Translation_Rot0 Translation_Rot0_1(r=l/2,w/2 - offset); Interfaces.Translation_Rot0 Translation_Rot0_2(r=l/2,0); Interfaces.Translation_Rot0 Translation_Rot0_3(r=l/2,-(w/2 - offset)); Interfaces.Translation_Rot0 Translation_Rot0_4(r=l/2,-(w/2 - offset)); Interfaces.Translation_Rot0 Translation_Rot0_5(r=l/2,0);
197
Interfaces.Translation_Rot0 Translation_Rot0_6(r=l/2,w/2 - offset); Interfaces.Translation_Rotminus90 Translation_Rotminus90_1(r=w/2,-(l/2 - offset)); Interfaces.Translation_Rotminus90 Translation_Rotminus90_2(r=w/2,0); Interfaces.Translation_Rotminus90 Translation_Rotminus90_3(r=w/2,l/2 - offset); Interfaces.Translation_Rot90 Translation_Rot90_1(r=-(l/2 - offset),w/2); Interfaces.Translation_Rot90 Translation_Rot90_2(r=0,w/2); Interfaces.Translation_Rot90 Translation_Rot90_3(r=l/2 - offset,w/2); equation connect(Resistor1.p, p2); connect(Resistor1.n, Pin1); connect(Resistor11.p, p12); connect(Resistor10.p, p11); connect(Resistor9.p, p10); connect(Resistor8.p, p9); connect(Resistor7.p, p8); connect(Resistor2.n, Pin1); connect(Resistor12.n, Pin1); connect(Resistor11.n, Pin1); connect(Resistor10.n, Pin1); connect(Resistor9.n, Pin1); connect(Resistor8.n, Pin1); connect(Resistor7.n, Pin1); connect(Resistor6.p, p7); connect(Resistor6.n, Pin1); connect(Resistor5.p, p6); connect(Resistor4.p, p5); connect(Resistor2.p, p3); connect(Resistor3.n, Pin1); connect(Resistor3.p, p4); connect(Resistor4.n, Pin1); connect(Resistor5.n, Pin1); connect(Resistor12.p, p1); connect(mems3, Translation_Rot0_1.MEMSConnector1); connect(Translation_Rot0_1.MEMSConnector2, MassBase1.memsC); connect(mems2, Translation_Rot0_2.MEMSConnector1); connect(Translation_Rot0_2.MEMSConnector2, MassBase1.memsC); connect(mems1, Translation_Rot0_3.MEMSConnector1); connect(Translation_Rot0_3.MEMSConnector2, MassBase1.memsC); connect(Translation_Rot0_6.MEMSConnector2, mems9);
198
connect(Translation_Rot0_6.MEMSConnector1, MassBase1.memsC); connect(Translation_Rot0_5.MEMSConnector2, mems8); connect(Translation_Rot0_5.MEMSConnector1, MassBase1.memsC); connect(Translation_Rot0_4.MEMSConnector2, mems7); connect(Translation_Rot0_4.MEMSConnector1, MassBase1.memsC); connect(mems6, Translation_Rotminus90_3.MEMSConnector1); connect(Translation_Rotminus90_3.MEMSConnector2, MassBase1.memsC); connect(mems5, Translation_Rotminus90_2.MEMSConnector1); connect(Translation_Rotminus90_2.MEMSConnector2, MassBase1.memsC); connect(mems4, Translation_Rotminus90_1.MEMSConnector1); connect(Translation_Rotminus90_1.MEMSConnector2, MassBase1.memsC); connect(Translation_Rot90_1.MEMSConnector2, mems12); connect(Translation_Rot90_1.MEMSConnector1, MassBase1.memsC); connect(Translation_Rot90_2.MEMSConnector2, mems11); connect(Translation_Rot90_2.MEMSConnector1, MassBase1.memsC); connect(Translation_Rot90_3.MEMSConnector2, mems10); connect(Translation_Rot90_3.MEMSConnector1, MassBase1.memsC); end PlateElement_Oriented
C.3.14 Uspring-Right Model
model Uspring_Right // the parameters public parameter Modelica.SIunits.Length L1=10e-6 "length of main arm in m"; parameter Modelica.SIunits.Length t1=2e-6 "width of main arm in m"; parameter Modelica.SIunits.Length L2=10e-6 "length of side arm in m"; parameter Modelica.SIunits.Length t2=2e-6 "width of side arm in m"; Interfaces.MEMSConnector MEMSConnector1; Interfaces.MEMSConnector MEMSConnector2; Modelica.Electrical.Analog.Interfaces.Pin Pin1; Modelica.Electrical.Analog.Interfaces.Pin Pin2; Elements.BeamElement BeamElement1(l=L1, w=t1); Elements.BeamElement BeamElement2(l=L2, w=t2); Elements.BeamElement BeamElement3(l=L1, w=t1); Elements.PlateElement_Oriented PlateElement_Oriented1(l=t2, w=t1); Elements.PlateElement_Oriented PlateElement_Oriented2(l=t2, w=t1); equation connect(BeamElement3.MEMSConnector1, MEMSConnector1);
199
connect(BeamElement3.PositivePin1, Pin2); connect(BeamElement1.MEMSConnector1, MEMSConnector2); connect(BeamElement1.PositivePin1, Pin1); connect(BeamElement2.PositivePin1, PlateElement_Oriented1.p11); connect(BeamElement2.MEMSConnector1, PlateElement_Oriented1.mems11); connect(BeamElement1.MEMSConnector2, PlateElement_Oriented1.mems2); connect(PlateElement_Oriented1.p2, BeamElement1.NegativePin1); connect(BeamElement2.NegativePin1, PlateElement_Oriented2.p5); connect(BeamElement2.MEMSConnector2, PlateElement_Oriented2.mems5); connect(BeamElement3.NegativePin1, PlateElement_Oriented2.p2); connect(BeamElement3.MEMSConnector2, PlateElement_Oriented2.mems2); end Uspring_Right
C.3.15 Uspring-Left Model
model Uspring_Left // the parameters public parameter Modelica.SIunits.Length L1=10e-6 "length of main arm in m"; parameter Modelica.SIunits.Length t1=2e-6 "width of main arm in m"; parameter Modelica.SIunits.Length L2=10e-6 "length of side arm in m"; parameter Modelica.SIunits.Length t2=2e-6 "width of side arm in m"; Interfaces.MEMSConnector MEMSConnector1; Modelica.Electrical.Analog.Interfaces.Pin Pin2; Modelica.Electrical.Analog.Interfaces.Pin Pin1; Interfaces.MEMSConnector MEMSConnector2; Elements.BeamElement BeamElement1(l=L1, w=t1); Elements.BeamElement BeamElement3(l=L1, w=t1); Elements.BeamElement BeamElement2(l=L2, w=t2); Elements.PlateElement_Oriented PlateElement_Oriented1(l=t2, w=t1); Elements.PlateElement_Oriented PlateElement_Oriented2(l=t2, w=t1); equation connect(BeamElement1.MEMSConnector2, MEMSConnector2); connect(BeamElement1.NegativePin1, Pin2); connect(BeamElement3.MEMSConnector2, MEMSConnector1); connect(BeamElement3.NegativePin1, Pin1); connect(BeamElement2.PositivePin1, PlateElement_Oriented1.p11);
200
connect(BeamElement2.MEMSConnector1, PlateElement_Oriented1.mems11); connect(BeamElement2.NegativePin1, PlateElement_Oriented2.p5); connect(BeamElement2.MEMSConnector2, PlateElement_Oriented2.mems5); connect(BeamElement3.MEMSConnector1, PlateElement_Oriented2.mems8); connect(PlateElement_Oriented2.p8, BeamElement3.PositivePin1); connect(PlateElement_Oriented1.p8, BeamElement1.PositivePin1); connect(PlateElement_Oriented1.mems8, BeamElement1.MEMSConnector1); end Uspring_Left
C.3.16 Resonator Model
model Resonator Interfaces.MEMSInertialSystem MEMSInertialSystem1; Elements.ElectrostaticPlateDrive ElectrostaticPlateDrive1( finger_length=13e-6, overlap=6e-6, gap=3e-6, fingers=10, Xc=0e-6, Yc=-87e-6, wing_length_a=2e-6, wing_length_b=7e-6, truss_width_a=1e-6, truss_width_b=1e-6); Elements.ElectrostaticPlateDrive ElectrostaticPlateDrive2( finger_length=13e-6, overlap=6e-6, gap=3e-6, fingers=10, Xc=0e-6, Yc=97e-6, wing_length_a=2e-6, wing_length_b=7e-6, truss_width_a=1e-6, truss_width_b=1e-6); Elements.Anchor Anchor5(r=0,-49e-6, angle=90); Elements.Anchor Anchor6(r=0,49e-6, angle=90); Modelica.Electrical.Analog.Interfaces.Pin Vin1; Modelica.Electrical.Analog.Interfaces.Pin Vin2; Modelica.Electrical.Analog.Interfaces.Pin Output; Elements.PlateElement_Oriented PlateElement_Oriented1(l=106e-6, w=5.5e-6); Elements.PlateElement_Oriented PlateElement_Oriented2( l=48e-6,
201
w=8.5e-6, offset=3.5e-6); Elements.PlateElement_Oriented PlateElement_Oriented3(l=13e-6, w=26e-6); Elements.PlateElement_Oriented PlateElement_Oriented4( l=48e-6, w=8.5e-6, offset=3.5e-6); Elements.PlateElement_Oriented PlateElement_Oriented5(l=106e-6, w=5.5e-6); Suspensions.Uspring_Right Uspring_Right1( L1=50e-6, L2=11e-6, t2=4e-6); Suspensions.Uspring_Right Uspring_Right2( L1=50e-6, L2=11e-6, t2=4e-6); Suspensions.Uspring_Left Uspring_Left1( L1=50e-6, L2=11e-6, t2=4e-6); Suspensions.Uspring_Left Uspring_Left2( L1=50e-6, L2=11e-6, t2=4e-6); Elements.CutAnchor CutAnchor2(r=24e-6,5e-6); Elements.CutAnchor CutAnchor3(r=-24e-6,5e-6, angle=0); Elements.CutAnchor CutAnchor4(r=-24e-6,-5e-6, angle=0); Elements.Anchor Anchor1(r=24e-6,-5e-6); equation connect(ElectrostaticPlateDrive2.PositivePin1, Output); connect(MEMSInertialSystem1.MEMSConnector1, Anchor5.frame_a); connect(PlateElement_Oriented1.mems11, PlateElement_Oriented2.mems5); connect(PlateElement_Oriented1.p11, PlateElement_Oriented2.p5); connect(PlateElement_Oriented3.p5, PlateElement_Oriented2.p11); connect(PlateElement_Oriented2.mems11, PlateElement_Oriented3.mems5); connect(PlateElement_Oriented4.mems5, PlateElement_Oriented3.mems11); connect(PlateElement_Oriented4.p5, PlateElement_Oriented3.p11); connect(PlateElement_Oriented5.p5, PlateElement_Oriented4.p11); connect(PlateElement_Oriented4.mems11, PlateElement_Oriented5.mems5); connect(PlateElement_Oriented5.mems11, ElectrostaticPlateDrive2. MEMSConnector1);
202
connect(PlateElement_Oriented5.p11, ElectrostaticPlateDrive2.NegativePin1); connect(Uspring_Left1.Pin1, Vin2); connect(Uspring_Left1.Pin2, PlateElement_Oriented2.p3); connect(Uspring_Left1.MEMSConnector2, PlateElement_Oriented2.mems3); connect(Uspring_Left2.Pin2, Vin2); connect(PlateElement_Oriented4.p1, Uspring_Left2.Pin1); connect(PlateElement_Oriented4.p9, Uspring_Right2.Pin2); connect(PlateElement_Oriented4.mems1, Uspring_Left2.MEMSConnector1); connect(Uspring_Right1.Pin1, PlateElement_Oriented2.p7); connect(Uspring_Right2.Pin1, Uspring_Right1.Pin2); connect(PlateElement_Oriented4.mems9, Uspring_Right2.MEMSConnector1); connect(Uspring_Right1.MEMSConnector2, PlateElement_Oriented2.mems7); connect(ElectrostaticPlateDrive1.PositivePin1, PlateElement_Oriented1.p5); connect(ElectrostaticPlateDrive1.MEMSConnector2, PlateElement_Oriented1. mems5); connect(ElectrostaticPlateDrive1.NegativePin1, Vin1); connect(ElectrostaticPlateDrive1.MEMSConnector1, Anchor5.frame_b); connect(CutAnchor2.MEMSConnector1, MEMSInertialSystem1.MEMSConnector1); connect(CutAnchor2.MEMSConnector2, Uspring_Right2.MEMSConnector2); connect(MEMSInertialSystem1.MEMSConnector1, CutAnchor3.MEMSConnector1); connect(CutAnchor3.MEMSConnector2, Uspring_Left2.MEMSConnector2); connect(MEMSInertialSystem1.MEMSConnector1, CutAnchor4.MEMSConnector1); connect(Uspring_Left1.MEMSConnector1, CutAnchor4.MEMSConnector2); connect(Anchor1.frame_a, MEMSInertialSystem1.MEMSConnector1); connect(Anchor1.frame_b, Uspring_Right1.MEMSConnector1); connect(ElectrostaticPlateDrive2.MEMSConnector2, Anchor6.frame_b); connect(Anchor6.frame_a, MEMSInertialSystem1.MEMSConnector1); end Resonator
C.3.17 Resonator Test Case Model
model TestResonator Resonator Resonator1;
203
Modelica.Electrical.Analog.Sources.ConstantVoltage ConstantVoltage1(V=10); Modelica.Electrical.Analog.Basic.Resistor Resistor1(R=10000); Modelica.Electrical.Analog.Sources.ConstantVoltage ConstantVoltage2(V=0); Modelica.Electrical.Analog.Basic.VCV VCV1(gain=1000); Modelica.Electrical.Analog.Basic.Ground Ground1; equation connect(ConstantVoltage1.p, Resonator1.Vin2); connect(ConstantVoltage2.n, Ground1.p); connect(Resonator1.Output, Resistor1.n); connect(Resistor1.p, VCV1.p2); connect(VCV1.n2, Ground1.p); connect(VCV1.n1, Resonator1.Output); connect(VCV1.p1, Ground1.p); connect(ConstantVoltage2.p, Resonator1.Vin1); connect(ConstantVoltage1.n, Ground1.p); end TestResonator
C.4 Component Interactions
C.4.1 MEMS Transformation Model
model MEMSTranslation extends TwoMEMSConnectors; parameter Modelica.SIunits.Position r[2]=0,0 "Vector from frame_a to frame_b resolved in frame_a"; parameter Real angle=0 "relative angle of frame_b wrt frame_a in [deg]"; protected Modelica.SIunits.Velocity vaux[2]; parameter Modelica.SIunits.Angle S_rel=angle*Modelica.Constants.pi/180 "angle in radians"; parameter Real Rot[2, 2]=cos(S_rel),sin(S_rel),-sin(S_rel),cos(S_rel) "relative transformation matrix of frame_a wrt frame_b"; equation Sb = Sa + S_rel; wb = wa; zb = za; r0b = r0a + cos(Sa),-sin(Sa),sin(Sa),cos(Sa)*r; vaux = wa*-r[2],r[1]; vb = Rot*(va + vaux);
204
ab = Rot*(aa + za*-r[2],r[1] + wa*-vaux[2],vaux[1]); /*Transform the force and torque acting at frame_b to frame_a*/ fa + transpose(Rot)*fb = 0,0; ta + tb - (r[1]*fa[2] - r[2]*fa[1]) = 0; end MEMSTranslation
C.4.2 Electrostatic Gap Model
model Electrostatic_ParallelPlate public parameter Modelica.SIunits.Length finger_width=2e-6 "width of fingers [m]"; parameter Modelica.SIunits.Length overlap=5e-6 "fingers overlap [m]"; parameter Modelica.SIunits.Distance gap=2e-6 "gap [m]"; parameter Modelica.SIunits.Distance offset=0 "offset [m]"; parameter Real fingers=3 "number of fingers"; parameter Real fringe_factor=0 "fraction increase in capacitance due to fringing effects"; protected package MEMS_Constants = CompSim.MEMS.MEMS_Constants; package Constants = Modelica.Constants; // port variables Modelica.SIunits.Voltage v "Voltage drop between the two electrical ports (= p.v - n.v)"; Modelica.SIunits.Current i "Current flowing from one electrical port to another"; Modelica.SIunits.Angle Sa; Modelica.SIunits.Position r0a[2]; Modelica.SIunits.Velocity va[2]; Modelica.SIunits.AngularVelocity wa; Modelica.SIunits.Acceleration aa[2]; Modelica.SIunits.AngularAcceleration za; Modelica.SIunits.Force fa[2]; Modelica.SIunits.Torque ta; Modelica.SIunits.Angle Sb; Modelica.SIunits.Position r0b[2]; Modelica.SIunits.Velocity vb[2]; Modelica.SIunits.AngularVelocity wb; Modelica.SIunits.Acceleration ab[2]; Modelica.SIunits.AngularAcceleration zb; Modelica.SIunits.Force fb[2]; Modelica.SIunits.Torque tb;
205
// relative kinematic variables Modelica.SIunits.Position r_rela[2]; // internal variables Modelica.SIunits.Capacitance C; Modelica.SIunits.Charge q; Real dCdz; parameter Modelica.SIunits.Area A=finger_width*overlap; public Interfaces.MEMSConnector MEMSConnector1( S=Sa, r0=r0a, v=va, w=wa, a=aa, z=za, f=fa, t=ta); Interfaces.MEMSConnector MEMSConnector2( S=Sb, r0=r0b, v=vb, w=wb, a=ab, z=zb, f=fb, t=tb); Modelica.Electrical.Analog.Interfaces.PositivePin PositivePin1; Modelica.Electrical.Analog.Interfaces.NegativePin NegativePin1; equation v = PositivePin1.v - NegativePin1.v; 0 = PositivePin1.i + NegativePin1.i; i = PositivePin1.i; // compute capacitance and its derivative C = (1 + fringe_factor)*MEMS_Constants.eps0*A/r_rela[1]; dCdz = -(1 + fringe_factor)*MEMS_Constants.eps0*A/(r_rela[1]*r_rela[1]); // compute current q = C*v; i = der(q); // compute forces and torques fb - fa = fingers*0.5*dCdz*v*v,0; fb + fa = 0,0; // fb - fa = fingers*0.5*dCdz*v*v,0; // fb + transpose(Rot)*fa = 0,0;
206
ta = 0; tb = 0; // define r_rela r0b = r0a + cos(Sa),-sin(Sa),sin(Sa),cos(Sa)*r_rela; end Electrostatic_ParallelPlate
C.5 External Sources
C.5.1 DC Voltage Source Model (from Modelica Electrical Library)
model ConstantVoltage "Source for constant voltage" parameter Modelica.SIunits.Voltage V=1 "Value of constant voltage"; extends Modelica.Electrical.Analog.Interfaces.OnePort; equation v = V; end ConstantVoltage
C.5.2 AC Voltage Source Model (from Modelica Electrical Library)
model SineVoltage "Sine voltage source" parameter Modelica.SIunits.Voltage V=1 "Amplitude of sine wave"; parameter Modelica.SIunits.Angle phase=0 "Phase of sine wave"; parameter Modelica.SIunits.Frequency freqHz=1 "Frequency of sine wave"; extends Modelica.Electrical.Analog.Interfaces.VoltageSource(redeclare Modelica.Blocks.Sources.Sine signalSource( amplitude=V, freqHz=freqHz, phase=phase)); end SineVoltage
C.5.3 Voltage-Controlled Voltage Source Model (from Modelica Electrical Library)
model VCV "Linear voltage-controlled voltage source" extends Modelica.Electrical.Analog.Interfaces.TwoPort; parameter Real gain=1 "Voltage gain"; equation v2 = v1*gain; i1 = 0; end VCV
C.5.4 External Force Model
model MEMSExtForce "External force"
207
Modelica.Blocks.Interfaces.InPort inPort(final n=2); CompSim.MEMS.Interfaces.MEMSConnector memsRight; equation memsRight.f = -inPort.signal; memsRight.t = 0; end MEMSExtForce
C.5.5 Sinusoidal Signal Model (from Modelica Block Library)
block Sine "Generate sine signals" parameter Real amplitude[:]=1 "Amplitudes of sine waves"; parameter SIunits.Frequency freqHz[:]=1 "Frequencies of sine waves"; parameter SIunits.Angle phase[:]=0 "Phases of sine waves"; parameter Real offset[:]=0 "Offsets of output signals"; parameter SIunits.Time startTime[:]=0 "Output = offset for time < startTime"; extends Interfaces.MO(final nout=max([size(amplitude, 1); size(freqHz, 1); size(phase, 1); size(offset, 1); size(startTime, 1)])); protected constant Real pi=Modelica.Constants.PI; parameter Real p_amplitude[nout]=(if size(amplitude, 1) == 1 then ones(nout) *amplitude[1] else amplitude); parameter Real p_freqHz[nout]=(if size(freqHz, 1) == 1 then ones(nout)* freqHz[1] else freqHz); parameter Real p_phase[nout]=(if size(phase, 1) == 1 then ones(nout)*phase[1 ] else phase); parameter Real p_offset[nout]=(if size(offset, 1) == 1 then ones(nout)* offset[1] else offset); parameter SIunits.Time p_startTime[nout]=(if size(startTime, 1) == 1 then ones(nout)*startTime[1] else startTime); equation for i in 1:nout loop outPort.signal[i] = p_offset[i] + (if time < p_startTime[i] then 0 else p_amplitude[i]*Modelica.Math.sin(2*pi*p_freqHz[i]*(time - p_startTime[i]) + p_phase[i])); end for; end Sine
208
Bibliography
[1] Adams, "http://www.adams.com,"., 2000.
[2] Agarwal, M., Cagan, J., and Constantine, K. G., "Influencing generative design
through continuous evaluation: associating costs with the coffeemaker shape
grammar," (AI EDAM) Artificial Intelligence for Engineering Design, Analysis and
Manufacturing, vol. 13, pp. 253-75, 1999.
[3] Agarwal, M. and Cagan, J., "On the use of shape grammars as expert systems for
geometry- based engineering design," (AI EDAM) Artificial Intelligence for
Engineering Design, Analysis and Manufacturing, vol. 14, pp. 431-9, 2000.
[4] Al-Ajmi, K. H., "Object-Oriented Modeling of Train Systems," in Electrical and
Computer Engineering. Pittsburgh, PA: Carnegie Mellon University, 2001.
[5] Allen, R. J. and Garlan, D., "Formalizing architectural connection," presented at
16th International Conference on Software Engineering, Sorrento, Italy, 1994.
[6] Ambler, A. P. and Popplestone, R. J., "Inferring the positions of bodies from
specified spatial relationships," Artificial Intelligence, vol. 6, pp. 157-174, 1975.
[7] Anantha, R., Kramer, G. A., and Crawford, R. H., "Assembly Modelling by
Geometric Constraint Satisfaction," Computer-Aided Design, vol. 28, pp. 707-722,
1996.
[8] Anderson, M., "Object-oriented modeling and simulation of hybrid systems," in
Department of Automatic Control. Lund, Sweden: Lund Institute of Technology,
1994.
209
[9] Andersson, K., "A vocabulary for conceptual design. Part of a design grammar,"
presented at Formal Design Methods for CAD. IFIP TC5/WG5.2 Workshop, Tallinn,
Estonia, 1994.
[10] Ansys, "Design Space,",, 6.0.1 ed: http://www.ansys.com, 2001.
[11] Ascher, U. M. and Petzold, L. R., Computer Methods for Ordinary Differential
Equations and Differential-Algebraic Equations. Philadelphia, Pennsylvania: SIAM,
1998.
[12] Avis, D. and Fukuda, K., "A Pivoting Algorithm for Convex Hulls and Vertex
Enumeration of Arrangements and Polyhedra," Discrete and Computational
Geometry, vol. 8, pp. 295-313, 1992.
[13] Avis, D., "A C Implementation of the Reverse Search Vertex Enumeration
Algorithm," in RIMS Kokyuroku 872, H. Imai, Ed. Kyoto: Kyoto University, 1994.
[14] Avis, D. and Fukuda, K., "Reverse Search for Enumeration," Discrete
Applied Mathematics, vol. 6, pp. 21-46, 1996.
[15] Avis, D., "Computational Experience with the Reverse Search Vertex
Enumeration Algorithm," Optimization Methods and Software, vol. 10, pp. 107-124,
1998.
[16] Baidya, B., Gupta, S. K., and Mukherjee, T., "Feature-Recognition For
MEMS Extraction," presented at ASME Design Engineering Technical Conferences,
Atlanta, Georgia, 1998.
[17] Baidya, B., Gupta, S. K., and Mukherjee, T., "MEMS Component Extraction,"
presented at International Conference on Modeling and Simluation of
Micorsystems, San Juan, Puerto Rico, 1999.
210
[18] Balci, O., "Principles of simulation model validation, verification, and testing,"
Transactions of the SCSI, vol. 14, pp. 3-12, 1998.
[19] Baldwin, C. Y. and Clark, K. B., Design Rules: The Power of Modularity, vol.
1: MIT Press, 2000.
[20] Baldwin, R. and Moon Jung, C., "Design methodology management using
graph grammars," presented at Proceedings of 31st ACM/IEE Design Automation
Conference, San Diego, CA, USA, 1994.
[21] Baraff, D., "Analytical methods for dynamic simulation of non-penetrating
rigid bodies," SIGGRAPH: Compputer Graphics, vol. 23, pp. 223-232, 1989.
[22] Barbour, N. and Schmidt, G., "Inertial sensor technology trends," presented
at 1998 Workshop on Autonomous Underwater Vehicles, Cambridge, MA, 1998.
[23] Bettig, B., Summers, J. D., and Shah, J. J., "Geometric Examplars: a Bridge
between CAD and AI," presented at The Fourth IFIP Working Group 5.2 Workshop
on Knowledge Intensive CAD (KIC-4), Parma, Italy, 2000.
[24] Boley, H., "Attribute Grammars and XML," presented at Workshop on
Attribute Grammars, XML and RDF, University of St. Gallen, 2000.
[25] Bremner, D., Fukuda, K., and Marzetta, A., "Primal-dual methods for vertex
and facet enumeration," Discrete Computational Geometry, vol. 20, pp. 333-357,
1998.
[26] Burckert, H.-J., Nutt, W., and Seel, C., "The role of formal knowledge
representation in configuration," presented at WRKP'96: Knowledge
Representation and Configuration Problems, DFKI GmbH, Kaiserslautern, 1996.
211
[27] Cadence, "Cadence,",, 4.4.5 ed. San Jose, CA: http://www.cadence.com,
2001.
[28] Cagan, J., "Discussion: research issues in the application of design
grammars," presented at Formal Design Methods for CAD. IFIP TC5/WG5.2
Workshop, Tallinn, Estonia, 1994.
[29] Carlson, C., "Shape grammars in design: discussion. Design space
description formalisms," presented at Formal Design Methods for CAD. IFIP
TC5/WG5.2 Workshop, Tallinn, Estonia, 1994.
[30] Cellier, F. E., "Object-oriented modeling: means for dealing with system
complexity," presented at 15th Benelux Meeting on Systems and Control, Mierlo,
Netherlands, 1996.
[31] Chan, B., "Supporting Conceptual Design: A methodology and infrastructure
for CAD," in Civil and Environmental Engineering. Pittsburgh: Carnegie Mellon
University, 1998, pp. 147.
[32] Chomsky, N., "On Certain Formal Properties of Grammars," Information and
Control, vol. 2, pp. 137-167, 1959.
[33] Daberkow, A. and Kreuzer, E. J., "An Integrated Approach for Computer-
Aided Design in Multibody System Dynamics," Engineering with Computers, vol.
15, pp. 155-170, 1999.
[34] Dani, T. H. and Gadh, R., "Networked Virtual Reality for Collaborative
Design," presented at 31st CIRP International Seminar on Manufacturing Systems,
Berkeley, CA, 1998.
212
[35] Darley, V., "Emergent Phenomena and Complexity," presented at Artificial
Life IV: Fourth International Workshop on the Synthesis and Simulation of Living
Systems, 1994.
[36] Deransart, P., Jourdan, M., and Lorho, B., "Survey on attribute grammars.
Part III. Classified bibliography,",, pp. 74, 1985.
[37] Deransart, P., Jourdan, M., and Lorho, B., "Survey on attribute grammars.
Part II. Review of existing systems,",, pp. 140, 1986.
[38] Deransart, P., Jourdan, M. M., and Lorho, B., "Survey on attribute grammars.
Part I. Main results on attribute grammars,",, pp. 54, 1986.
[39] Devedzic, V., "A survey of modern knowledge modeling techniques," Expert
systems with applications, vol. 17, pp. 275-294, 1999.
[40] Dewey, A., Srinivasan, V., and Icoz, E., "Towards a Visual Modeling
Approach to Designing Microelectromechanical System (MEMS) Transducers,"
Journal of Micromechanics and Microengineering, vol. 9, pp. 332-340, 2000.
[41] Diaz-Calderon, A., Paredis, C. J. J., and Khosla, P. K., "A composable
simulation environment for mechatronic systems," presented at SCS 1999
European Simulation Symposium, Erlangen, Germany, 1999.
[42] Diaz-Calderon, A., Paredis, C. J. J., and Khosla, P. K., "Organization and
selection of reconfigurable models," presented at Proceedings of WSC 2000,
Winter Simulation Conference, Orlando, FL, USA, 2000.
[43] Duckering, B. C., "Behavioral Modeling Technology: Leveraging Engineering
Knowledge in CAD Models," presented at The Fourth IFIP Working Group 5.2
Workshop on Knowledge Intensive CAD (KIC-4), Parma, Italy, 2000.
213
[44] Dynasim Ab, "Dymola,". Lund, Sweden: Dynasim AB, 1999.
[45] Economakos, G., Papakonstantinou, G., and Tsanakas, P., "AGENDA: an
attribute grammar driven environment for the design automation of digital systems,"
presented at Proceedings Design, Automation and Test in Europe, Paris, France,
1998.
[46] Economakos, G. and Papakonstantin, G., "An attribute grammar driven high-
level synthesis methodology for VHDL specifications," presented at Proceedings of
SCS'99: International Symposium on Signals, Circuits and Systems, Iasi, Romania,
1999.
[47] Economakos, G. and Papakonstantinou, G., "Refinement and property
checking in high-level synthesis using attribute grammars," presented at
Proceedings of 10th Conference on Correct Hardware Design and Verification
Methods, Bad Herrenalb, Germany, 1999.
[48] Economakos, G. and Papakonstantinou, G., "A formal method for hardware
design using attribute grammars," presented at ICECS'99. Proceedings of
ICECS'99. 6th IEEE International Conference on Electronics, Circuits and Systems,
Pafos, Cyprus, 1999.
[49] Elmqvist, H., Mattsson, S. E., and Otter, M., "Modelica: The new object-
oriented modeling language," presented at The 12th European Simulation
Multiconference, Manchester, UK, 1998.
[50] Erdogmus, H., "A formal framework for software architectures," Institute for
Information Technology, National Research Council, Ottawa, Canada ERB 1047 /
NRC 40136, December 1995.
214
[51] Farrow, R., Marlowe, T. J., and Yellin, D. M., "Composable attribute
grammars: support for modularity in translator design and implementation,"
Conference Record of the Nineteenth Annual ACM SIGPLAN- SIGACT Symposium
on Principles of Programming Languages, pp. viii+366, 223-34, 1992.
[52] Fedder, G. K. and Qi, J., "A hierarchical circuit-level design methodology for
microelectromechanical systems," IEEE Transactions on Circuits and Systems II:
Analog and Digital Signal Processing, vol. 46, pp. 1309-15, 1999.
[53] Feldkamp, F., Heinrich, M., and Meyer-Gramann, K. D., "SyDeR— System
design for reusability," Artificial Intelligence for Engineering, Design, Analysis and
Manufacturing, vol. 12, pp. 373-382, 1998.
[54] Fishwick, P. A., "Integrating Continuous And Discrete Models With Object
Oriented Physical Modeling," presented at 1997 Western Simulation
Multiconference, Phoenix, Arizona, 1997.
[55] Fitzhorn, P. A., "Engineering design is a computable function," (AI EDAM)
Artificial Intelligence for Engineering Design, Analysis and Manufacturing, vol. 8, pp.
35-44, 1994.
[56] Fukuda, K., "Note on new complexity classes ENP, EP and CEP - An
extension of the classes NP ∩ co-NP and P," ETH Zürich, Institute for Operations
Research, Zürich June 12, 1996 1996.
[57] Fukuda, K. and Prodon, A., "Double description method revisited," in
Combinatorics and Computer Science, vol. 1120, Lecture Notes in Computer
Science, M.Deza, R. Euler, and I. Manoussakis, Eds.: Springer-Verlag, 1996, pp.
91-111.
215
[58] Gandhi, M. and Robertson, E. L., "A specification-based data model,"
presented at 11th International Conference on the Entity-Relationship Approach,
ER'92, Karlsruhe, Germany, 1992.
[59] Ge, Q. and Mccarthy, J. M., "Functional Constraints as Algebraic Manifolds
in a Clifford Algebra," IEEE Journal Robotics and Automation, vol. 7, pp. 670-677,
1991.
[60] Goldman, A. J. and Tucker, A. W., "Polyhedral Convex Cones," in Linear
Inequalities and Related Systems, vol. 39, Annals of Math Studies, H. W. Kuhn and
A. W. Tucker, Eds. Princeton, NJ: Princeton University Press, 1956, pp. 19-39.
[61] Gray, A., Modern Differential Geometry of Curves and Surfaces with
Mathematica. New York, NY: CRC Press, 1998.
[62] Gupta, S. K., Paredis, C. J. J., Sinha, R., and Brown, P. F., "Intelligent
Assembly Modeling and Simulation," Assembly Automation, vol. 21, pp. 215-235,
2001.
[63] Haas, S. and Jasnoch, U., "Cooperative Working on Virtual Prototypes,"
presented at IFIP Workshop on Virtual Prototyping, Providence, RI, 1994.
[64] Hayden, S. and Kennison, J. F., Zermelo-Fraenkel Set Theory, 1 ed.
Columbus, OH: Charles E. Merrill Publishing Co., 1968.
[65] Hedin, G., Ohlsson, L., and Mckenna, J., "Product configuration using object
oriented grammars," presented at System Configuration Management. ECOOP'98
SCM-8 Symposium. Proceedings, Brussels, Belgium, 1998.
216
[66] Hirai, S. and Asada, H., "Kinematics and Statics of Manipulation Using the
Theory of Polyhedral Convex Cones," International Journal of Robotics Research,
vol. 12, pp. 434-447, 1993.
[67] Hofmann, K., Lang, M., Karam, J. M., Glesner, M., and Courtois, B.,
"Generation O: a behavioral model of an acceleration sensor from its finite-element-
description," presented at Third France-Japan Congress and First Europe-Asia
Congress on Mechatronics, Besancon, France, 1996.
[68] Holmgren, F., "A Grammar-based Approach to Design and its Application to
Electronics and Logic Programming," in Department of Computer and Systems
Sciences. Stockholm, Sweden: Stockholm University, 1997.
[69] Hua, K., Faltings, B., and Smith, I., "CADRE: case-based geometric design,"
Articial Intelligence in Engineering, vol. 10, pp. 171-183, 1996.
[70] IEEE, 1076.1 Working Group: Analog and mixed-signal extensions for
VHDL: IEEE, 1999.
[71] Irwin, J. D. and Wu, C.-H., Basic Engineering Circuit Analysis, 6th ed. Upper
Saddle River, NJ: Prentice-Hall, 1999.
[72] Ivezic, N., "Simulation-Based Support for Early Collaborative Design," in Civil
and Environmental Engineering. Pittsburgh: Carnegie Mellon University, 1995, pp.
158.
[73] Iyer, S. V., "Layout Synthesis of Microresonators," in Electrical and Computer
Engineering. Pittsburgh: Carnegie Mellon University, 1998.
217
[74] Keirouz, W., Shooter, S., and Szykman, S., "A Model for the Flow of Design
Information in OpenADE," National Institute for Standards and Technology,
Gaithersburg, MD NIST internal report, 2000.
[75] Kim, S. H. and Lee, K., "An assembly modeling system for dynamic and
kinematic analysis," Computer Aided Design, vol. 21, pp. 2-12, 1989.
[76] Knuth, D. E., "Semantics of context-free languages," Mathematical Systems
Theory, vol. 2, pp. 127-46, 1968.
[77] Ko, H. and Lee, K., "Automatic assembling procedure generation from
mating conditions," Computer-Aided Design, vol. 19, pp. 3-10, 1987.
[78] Landin, J., An Introduction to Algebraic Structures: Dover Publications, 1989.
[79] Lee, E. A. and Xiong, Y., "System-level types for component-based design,"
University of California at Berkeley, Berkeley, CA ERL/UCB M 00/8, February 29
2000.
[80] Liang, V.-C., "personal communication,",, R. Sinha, Ed. Pittsburgh, PA, 2002.
[81] Lin, S.-T. and Lin, J.-H., "Computer Aided Dynamic Analysis and Simulation
of Multibody Mechanical Systems in AutoCAD," Simulation, vol. 71, pp. 328-335,
1998.
[82] Liu, Y. and Popplestone, R., "A Group Theoretic Formalization of Surface
Contact," International Journal of Robotics Research, vol. 13, pp. 148-161, 1994.
[83] Lu, M. S.-C. and Fedder, G. K., "Parameterized Electrostatic Gap Models for
Structured Design of Microelectromechanical Systems," presented at International
Conference on Modeling and Simluation of Micorsystems, San Juan, Puerto Rico,
1999.
218
[84] Magee, J., Dulay, N., Eisenbach, S., and Kramer, J., "Specifying Distributed
Software Architectures," presented at 5th European Software Engineering
Conference, ESEC'95, Barcelona, Spain, 1995.
[85] Maher, M. L. and De Silva, G. A. G., "Developing case-based reasoning for
structural design," IEEE Expert, vol. 11, pp. 42-52, 1996.
[86] Mattikalli, R. and Khosla, P. K., "Analysis of restraints to translational and
rotational motion from the geometry of contact," presented at ASME Winter Annual
Meeting, Atlanta, 1991.
[87] Mattikalli, R., Barraff, D., and Khosla, P. K., "Finding All Gravitationally Stable
Orientations of Assemblies," presented at IEEE International Conference on
Robotics and Automation, San Diego, CA, 1994.
[88] Mattikalli, R., Baraff, D., Khosla, P., and Repetto, B., "Gravitational Stability
of Frictionless Assemblies," IEEE Transactions on Robotics and Automation, vol.
11, pp. 374-388, 1995.
[89] Mattsson, S. E., Elmqvist, H., and Otter, M., "Physical system modeling with
Modelica," Control Engineering Practice, vol. 6, pp. 501-510, 1998.
[90] Mechanical Dynamics Inc., "ADAMS,".: Mechanical Dynamics Inc., 1999.
[91] Motta, E. and Zdrahal, Z., "Parametric Design Problem Solving," presented
at 10th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop
(KAW'96), Banff, Alberta, Canada, 1996.
[92] Motzkin, T. S., Raiffa, H., Thompson, G. L., and Thrall, R. M., "The Double
Description Method," in Contributions to the Theory of Games, vol. 2, H. W. Kuhn
and A. W. Tucker, Eds. Princeton, NJ: Princeton University Press, 1953.
219
[93] Mukherjee, T., Iyer, S., and Fedder, G. K., "Optimization-based synthesis of
microresonators," presented at 9th International Solid State Sensors and Actuators
Conference (Transducers '97), Chicago, IL, USA, 1997.
[94] Mukherjee, T. and Fedder, G. K., "Hierarchical Mixed-Domain Circuit
Simulation, Synthesis and Extraction Methodology for MEMS," Journal of VLSI
Signal Processing-Systems for Signal, Image and Video Technology, pp. 233-249,
1999.
[95] Mukherjee, T. and Fedder, G. K., "Hierarchical mixed-domain circuit
simulation, synthesis and extraction methodology for MEMS," Journal of VLSI
Signal Processing Systems for Signal, Image, and Video Technology, vol. 21, pp.
233-49, 1999.
[96] Mukherjee, T., Zhou, Y., and Fedder, G. K., "Automated optimal synthesis of
microaccelerometers," presented at Proceedings of 12th International Workshop on
Micro Electro Mechanical Systems - MEMS, Orlando, FL, USA, 1999.
[97] Mullins, S. and Rinderle, J. R., "Grammatical approaches to engineering
design. I. An introduction and commentary," Research in Engineering Design, vol.
2, pp. 121-35, 1991.
[98] Nemhauser, G. L. and Wolsey, L. A., Integer and Combinatorial Optimization.
New York: John Wiley, 1988.
[99] Neul, R., Becker, U., Lorenz, G., Schwarz, P., Haase, J., and Wünsche, S.,
"A Modeling Approach to Include Mechanical Microsystem Components into the
System Simulation," presented at 1998 Design Automation and Test in Europe,
Paris, FRANCE, 1998.
220
[100] O'brien, J. and Hodgins, J., "Graphical modeling and animation of brittle
fracture," presented at SIGGRAPH, Los Angeles, CA, USA, 1999.
[101] Ohwovoriole, M. S. and Roth, B., "An extension of screw theory," ASME
Journal of Mechanical Design, vol. 103, pp. 725-735, 1981.
[102] Orlandea, N., Chace, M. A., and Calahan, D. A., "A sparsity-oriented
approach to the dynamic analysis and design of mechanical systems - Part 2,"
Journal of Engineering for Industry, pp. 780-784, 1977.
[103] Orlandea, N., Chace, M. A., and Calahan, D. A., "A sparsity-oriented
approach to the dynamic analysis and design of mechanical systems - Part 1,"
Journal of Engineering for Industry, pp. 773-779, 1977.
[104] Ozawa, M., Cutkosky, M. R., and Howley, B. J., "Model Sharing among
Agents in a Concurrent Product Development Team," presented at Workshop on
Knowledge Intensive CAD, KIC-3, IFIP 5.2 Working Group, Tokyo, Japan, 1998.
[105] Pahl, G. and Beitz, W., Engineering design: A systematic approach, 2nd ed.
London, U.K.: Springer-Verlag, 1996.
[106] Paredis, C. J. J., Diaz-Calderon, A., Sinha, R., and Khosla, P. K.,
"Composable Models for Simulation-Based Design," Engineering with Computers,
vol. 17, pp. 112-128, 2001.
[107] Parisi-Presicce, F., "Modular system design applying graph grammars
techniques," Automata, Languages and Programming. 16th International
Colloquium Proceedings, pp. xi+788, 621-36, 1989.
[108] Paul, B., Kinematics and Dynamics of Planar Machinery. Englewood Cliffs,
NJ: Prentice-Hall Inc., 1979.
221
[109] Paynter, H. M., Analysis and design of engineering systems. Cambridge,
MA: MIT Press, 1961.
[110] Ptc, "Pro/ENGINEER 2000i2,".: PTC, 2000.
[111] Qureshi, S., Shah, J., Sunderarajan, K. G., Urban, S., Harter, E., Parazzoli,
C., and Bluhm, T., "A Framework for Providing an Integrated View of
electromechanical Product Design Information," presented at TeamCAD: GVU/NIST
workshop on Collaborative Design, Atlanta, Geogia, 1997.
[112] Rajan, V., Lyons, K., and Sreerangam, R., "Generation of component
degrees of freedom from assembly surface mating constraints," presented at 1997
ASME Design Engineering Technical Conference, Sacramento, CA, 1997.
[113] Rajan, V. N. and Nof, S. Y., "Minimal Precedence Constraints for Integrated
Assembly and Execution Planning," IEEE Trans. Robotics and Automation, vol. 12,
pp. 175-186, 1996.
[114] Revesz, G. E., Introduction to Formal Languages: Dover Publications, 1991.
[115] Rinderle, J. R., "Grammatical approaches to engineering design. II. Melding
configuration and parametric design using attribute grammars," Research in
Engineering Design, vol. 2, pp. 137-46, 1991.
[116] Rivard, H. and Fenves, S., "A representation for conceptual design of
buildings," Journal of Computing in Civil Engineering, pp. 151-159, 2000.
[117] Rocheleau, D. N., "An assembly representation for articulated mechanisms,"
presented at Engineering Systems Design and Analysis Conference, 1996.
[118] Romanowicz, B. F., Methodology for the Modeling and Simulation of
Microsystems: Kluwer Academic Publishers, 1998.
222
[119] Salustri and Venter, "An Axiomatic Theory of Engineering Design
Information," Engineering with Computers, vol. 8, pp. 197-211, 1992.
[120] Sariyildiz, S., Durmisevic, S., and Ciftcioglu, O., "Integrating pattern grammar
and wavelets in architectural design," presented at 6th International Conference on
Computer Graphics and Visualization 98, Plzen, Czech Republic, 1998.
[121] Sattler, U., "Description Logics for the Representation of Aggregated
Objects," presented at 14th European Conference on Artificial Intelligence, Berlin,
Germany, 2000.
[122] Schlenoff, C., Denno, P., Ivester, R., Szykman, S., and Libes, D., "An
Analysis of existing ontological systems for applications in manufacturing,"
presented at ASME DETC 19th Computers and Information in Engineering
Conference, Las Vegas, Nevada, 1999.
[123] Senturia, S. D., Microsystem Design. Boston: Kluwer Academic Publishers,
2001.
[124] Shah, J. J. and Mantyla, M., Parametric and Feature-Based CAD/CAM:
Concepts, Techniques, Applications. New York, NY: John Wiley & Sons, 1995.
[125] Shea, K. and Cagan, J., "Languages and semantics of grammatical discrete
structures," (AI EDAM) Artificial Intelligence for Engineering Design, Analysis and
Manufacturing, vol. 13, pp. 241-51, 1999.
[126] Shetty, D. and Kolk, R., Mechatronics System Design, 1 ed: Brooks/Cole
Pub Co, 1997.
223
[127] Shooter, S. B., Keirouz, W., Szykman, S., and Fenves, S. J., "A model for the
flow of design information," presented at ASME DETC 2000, 12th International
Conference on Design Theory and Methodology, Baltimore, MD, 2000.
[128] Sinha, R., Paredis, C. J. J., Gupta, S. K., and Khosla, P. K., "Capturing
articulation in assemblies from component geometry," presented at ASME Design
Engineering Technical Conference, Atlanta, GA, 1998.
[129] Sinha, R., Paredis, C. J. J., and Khosla, P. K., "Kinematics Support for
Design and Simulation of Mechatronic Systems," presented at The Fourth IFIP
Working Group 5.2 Workshop on Knowledge Intensive CAD (KIC-4), Parma, Italy,
2000.
[130] Sinha, R., Paredis, C. J. J., and Khosla, P. K., "Integration of mechanical
CAD and behavioral modeling," presented at Proceedings 2000 IEEE/ACM
International Workshop on Behavioral Modeling and Simulation, Orlando, FL, USA,
2000.
[131] Sinha, R., Paredis, C. J. J., and Khosla, P. K., "Interaction Modeling in
Systems Design," presented at ASME Design Engineering Technical Conferences,
Pittsburgh, PA, 2001.
[132] Sinha, R., Gupta, S. K., Paredis, C. J. J., and Khosla, P. K., "Extracting
Articulation Models from CAD Models of Parts with Curved Surfaces," ASME J. of
Mechanical Design, pp. in press, 2002.
[133] Sinha, R., Paredis, C. J. J., and Khosla, P. K., "Automatic Behavioral Model
Composition in Simulation-Based Design," presented at 35th Annual Simulation
Symposium, San Diego, CA, 2002.
224
[134] Spell, B., Professional Java Programming: Class Design, Threads, Event
Handling, Layout Managers, Swing Components, JDBC, XML, Security, JavaHelp,
JNI, Performance, and Distributed Objects: Mass Market Paperback, 2000.
[135] Spivey, J. M., The Z notation: A reference manual, 2nd ed. New York:
Prentice Hall International, 1992.
[136] Stein, J. L. and Louca, L. S., "A component-based modeling approach for
systems design: Theory and implementation," presented at International
Conference on Bond Graph Modeling and Simulation, Las Vegas, NV, 1995.
[137] Strauss, J. C., Augustin, D. C., Fineberg, M. S., Johnson, B. B., Linebarger,
R. N., and Sanson, F. J., "The SCI continuous system simulation language
(CSSL)," Simulation, vol. 9, pp. 281-303, 1967.
[138] Susca, L., Mandorli, F., and Rizzi, C., "How to Represent "Intelligent"
Components in a Product Model: a Practical Example," presented at The Fourth
IFIP Working Group 5.2 Workshop on Knowledge Intensive CAD (KIC-4), Parma,
Italy, 2000.
[139] Swenson, D. V. and Ingraffea, A. R., "Modelling Mixed-Mode Dynamic Crack
Propagation Using Finite Elements: Theory and Applications," Computational
Mechanics, vol. 3, pp. 187-192, 1988.
[140] Sycara, K. and Navinchandra, D., "Retrieval Strategies in a Case-Based
Design System," in Artificial Intelligence in Engineering Design, Volume II, C. Tong
and D. Sriram, Eds.: Academic Press Inc., 1992.
[141] Sydow, A., "Hierarchical Concepts in Modeling and Simulation," in Progress
in Modeling and Simulation, F. E. Cellier, Ed. London: Academic Press, 1982.
225
[142] Taentzer, G. and Schween, H., "Movement of objects in configuration spaces
modelled by graph grammars," Graph Grammars and Their Application to
Computer Science. 4th International Workshop. Proceedings, pp. x+703, 660-75,
1991.
[143] Tanaka, T., "Definite-clause set grammars: a formalism for problem solving,"
Journal of Logic Programming, vol. 10, pp. 1-17, 1991.
[144] Tanaka, T. and Jain, L. C., "Circuit representation in a logic grammar,"
presented at Proceedings Electronic Technology Directions to the Year 2000,
Adelaide, SA, Australia, 1995.
[145] Tang, W. C., Nguyen, T. C. H., Judy, M. W., and Howe, R. T., "Electrostatic-
comb drive of lateral polysilicon resonators," presented at 5th International
Conference on Solid-State Sensors and Actuators and Eurosensors III, Montreux,
Switzerland, 1989.
[146] Tang, W. C., "Overview of microelectromechanical systems and design
processes," presented at 34th annual conference on Design automation
conference, Anaheim, California, 1997.
[147] The Mathworks Inc., "Matlab/Simulink,".: The Mathworks Inc., 1999.
[148] Thomas, F. and Torras, C., "Inferring Feasible Assemblies from Spatial
Constraints," IEEE Transactions on Robotics and Automation, vol. 8, pp. 228-239,
1992.
[149] Tilove, R., "Extending solid modeling systems for mechanism design and
kinematic simulation," IEEE CG&A, pp. 9-19, 1983.
226
[150] Tsai, Chang, and Wang, "Integration intfrastructure for a simulation-based
design environment," presented at ASME Computers in Engineering Conference,
1995.
[151] Turner, J., Subramaniam, S., and Gupta, S., "Constraint representation and
reduction in assembly modeling and analysis," IEEE Transactions on Robotics and
Automation, vol. 8, pp. 741-750, 1992.
[152] Tyugu, E., "Attribute models of design objects," presented at Formal Design
Methods for CAD. IFIP TC5/WG5.2 Workshop, Tallinn, Estonia, 1994.
[153] Upton, J., "Boeing 777," in Airlinertech Series, vol. 2, 2 ed: Specialty Press,
1998.
[154] Vemuri, S., Fedder, G. K., and Mukherjee, T., "Low-Order Squeeze Film
Model for Simulation of MEMS Devices," presented at International Conf. on
Modeling and Simulation of Microsystems Semiconductors, Sensors and Actuators
(MSM 00), San Diego, CA, 2000.
[155] W3c, "Extensible Markup Language (XML),".: World Wide Web Consortium,
1999.
[156] Wache, H. and Kamp, G., "Using description logic for configuration
problems," presented at WRKP'96: Knowledge Representation and Configuration
Problems, DFKI GmbH, Kaiserslautern, 1996.
[157] Warren, J. R. and Crosslin, R. L., "Development of a system simulation
grammar for systems analysis and design," Proceedings of the 1990 Summer
Computer Simulation Conference, pp. xix+1202, 880-5, 1990.
227
[158] Watson, I. and Perera, S., "Case-based design: A review and analysis of
building design applications," Articial Intelligence for Engineering Design, Analysis
and Manufacturing: AIEDAM, vol. 11, pp. 59-87, 1997.
[159] Whitney, Nevins, Fazio, D., and Gustavson, "Problems and Issues in Design
and Manufacture of Complex Electro-mechanical Systems,",, Laboratory Report R-
2577, January 1994.
[160] Whitney, D. E., "Why Mechanical Design Cannot Be Like VLSI Design," MIT
4-4-96 1996.
[161] Wilson, N. M., Dutton, R. W., and Pinsky, P. M., "Investigation of tetrahedral
automatic mesh generation for finite-element simulation of micro-electro-
mechanical switches," presented at International Conference on Modeling and
Simulation of Microsystems, Semiconductors, Sensors and Actuators, San Juan,
Argentina, 1999.
[162] Wilson, R. H. and Latombe, J.-C., "Geometric reasoning about mechanical
assembly," Artificial Intelligence, vol. 71, pp. 371-396, 1994.
[163] Yazdi, N., Ayazi, F., and Najafi, K., "Micromachined inertial sensors,"
Proceedings of the IEEE, vol. 86, pp. 1640-59, 1998.
[164] Zeigler, B. P. and Luh, C.-J., "Model based management for multifacetted
systems," ACM Transactions on Modeling and Computer Simulation, vol. 1, pp.
195-218, 1991.
[165] Zeigler, B. P., Praehofer, H., and Kim, T. G., Theory of Modeling and
Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems,
2nd ed: Academic Press, 2000.
228
[166] Zhang, G. and Zeigler, B. P., "The system entity structure: Knowledge
representation for simulation modeling and design," in Artificial Intelligence,
Simulation and Modeling, L. E. Widman, K. A. Loparo, and N. R. Nielsen, Eds. New
york: Wiley, 1989, pp. 47-73.