High Level Model Integration for Design of Mechatronic Systems

Andres A. Alvarez Cabrera, Mustafa S. Erden, Maarten J. Foeken, and Tetsuo Tomiyama, Member,
IEEE and ASME

Abstract-Development of mechatronic products, and their system by using a central, high level, model of the system
controllers, carries a series of difficulties related mainly to and its behavior.
product complexity. This paper discusses such difficulties and A first case study is introduced in the paper to provide
introduces a proposal of a framework of prototype tools that practical examples to a number of the discussed topics and
aim to support controller design for mechatronic systems by
prviin coto otaegnrto. to tis to dnumbroft
illustrate some related discussed The csacase
industrial approaches.
providing control software generation. Thi wokepaie
This work emphasizes stdcorpnstohewkprfmdbyheahrst
the high level system description embedded in such framework study corresponds to the work performed by the authors at
and the model integration aspects. Philips Applied Technologies to study the potential of
automatic data transfer between modeling tools used in the
I. INTRODUCTION design of a two-stage, high-precision, magnetic levitation
A]\4ECHATRONIC systems encompass a large variety of positioning platform.
IV.i products characterized by the synergic integration of F conl
mechanics, electronics, and information technology.
*
.oe
~~~~~~~~~~~~~Intgrtio
Frmw k
Development of such products brings new challenges to the r
Function Modeling (Modes, Communication, User Interaction)
designers because mechatronic systems tend to be inherently
complex. Understanding the sources of complexity is
fundamental to improve design of the control system for
these products, and appropriate modeling and design support Mhs Qualitative
tools are essential to deal with system complexity. Generation
The Automatic Generation of Control Software for .e.t.... ......t...
Mechatronic Systems project aims to develop a set of Prdt Definition i
prototype tools and a framework (see Fig. 1) to facilitate
seamless integration among available modeling tools, so that r Mechanical Quantitative ~ ~ r-7 otolrDsg
an interdisciplinary pro uc eve opmen eam can (almost)
productddevelopment-teamcan(almost) Embodiment Design 'Behavior Generation,

automatically generate control software for mechatronic

machines. The project contemplates high level modeling (i.e.
functional modeling) and reasoning from model information
(i.e. qualitative reasoning) as part of the integration goal, .
and to endow the set of models with the necessary Control Code
Generation
Control Model
Generation
information to generate control software.
This paper focuses on the high level system description in M & 'D'
Prototype Ct11re 1'''''''Model''' Pr-toty'e
the mentioned framework, as well as on aspects of model
integration (blocks encircled in dash-dot lines in Fig. 1). In Softvare Level Hardware & Machine
general, the paper proposes to integrate a set of models of a Verification Level Verification
Fig. 1. Architecture of the proposed control software generation
The authors gratefully acknowledge the support of the Dutch Innovation framework. Black dash-lined blocks correspond to existing, commercial
Oriented Research Program 'Integrated Product Creation and Realization modeling tools.
(IOP-IPCR)' of the Dutch Ministry of Economic Affairs. To establish some common ground, section II deals with
Andres A. Alvarez Cabrera is a Ph.D. researcher at the Faculty of general aspects of mechatronic systems and their design.
Mechanical, Maritime, and Materials Engineering at Delft University of Section III continues with an overview about systems
Technology (TUDelft), Mekelweg 2, 2628 CD, Delft, The Netherlands
(corresponding author, phone: +31-(0)15-278-7348; e-mail: modeling, integration, and problems related to complexity.
a.a.alvarezcabrera@tudelft.nl). Section IV discusses the case study. Next, after mentioning
Mustafa S. Erden is a post doctoral researcher at the Faculty of
TX 4.1_-
~ 4-._ .%~_;]
Mechanical, .
Maritime,
Tx r+TNIV
-A Materials Engineering at Delfi University
and T_--+ Of some related work, section V introduces
soerltdwr,scin the
nrdcstepooe proposed
Technology (TUDelfi) (e-mail: m.s.erden@tudelft.nl). approach for model integration and exposes some related
Maarten J. Foeken is a Ph.D. researcher at the Faculty of Aerospace aspects. The paper ends with the conclusions section.
Engineering at Delfi University of Technology (TUDelfi) (e-mail:
m.j.foeken@tudelft.nl).
Prof. Dr. Tetsuo Tomiyama is Professor at the Faculty of Mechanical, II. MECHATRONIC SYSTEMS AND THEIR CONTROL
Maritime, and Materials Engineering at Delfi University of Technology Fist it iscnein-oetbihsm omngon
(TUDelfi) (e-mail: t.tomiyama@tudelft.nl).

1-4244-2368-2/08/$20.OO ©)2008 IEEE 387

about mechatronic systems, mentioning some distinctive explain complexity in this context ([1]-[3], [5]):
aspects and problems related to their design and control. --The multidisciplinary nature of the mechatronic systems
A definition for mechatronic systems that shares some of requires careful consideration of interactions coming from
the most common aspects from the different definitions that integrating subsystems.
can be found in literature is ([1]-[5]): A mechatronic system --The modem tendency to seek flexibility (as multiple
is one that contains a synergic integration of applied function achievement and as adaptability) in mechatronic
principles from mechanics, electronics, and information products. A flexible mechatronic product is more complex
technology. Usually the electronic and software parts of the than one that performs less functions or that only works in a
system are responsible of the information handling and the very restricted environment.
control of the system. --The sheer "size" of the mechatronic product design.
Even mechatronic products that do not contain many
A. Particularities in the design of mechatronic systems
YS mechan conetpossess
~~mechanical some for
components possess some oftintrang
form of interfacing
With the previous definition in mind we can say that, (system and user interfacing) and control that requires
ideally, when designing a mechatronic system the possible detailed models and specifications for software and
interactions of disciplines must be considered at all stages. electronics.
This allows obtaining a design that integrates synergically
the involved domains and subsystems. In fact, the concept of B. Highlights about controller design in mechatronic
mechatronics shares much with the concurrent engineering systems
approach of product development [6]. Control constitutes a significant part of the design of
Nowadays still exist situations where the design of mechatronic systems ([1], [3]). A proper choice of the
mechatronic systems is carried in an independent manner for control architecture in a system is not only critical to
each involved domain ([7], [8]), only maintaining in guarantee that the necessary system factors are controlled
common the requirements specified at the conceptual stage. [2], but also effectively influences the development
Then the resulting parts are assembled forming a consistent efficiency and the performance of the mechatronic system.
unit. Some times it is wrongfully assumed that the design is As mentioned before, quite often the controller design is
integral or concurrent because design activities are not considered carefully in the conceptual stage of product
performed parallelly in time. Though this is a valid design development. An example of this is given in [8], where the
approach, it is worth mentioning some related problems: authors comment on the consequences of disregarding
--Separate subsystems are designed considering only the controller design in the conceptual phase: "The common
intended interfacing between them, thus neglecting other approach for the machine tool design would (...) come up
unintended forms of interaction. with a very stif structure, and then move on ahead for a
--As the full set of relevant forms in which subsystems prototype machine tool manufacturingfor servo tuning. This
interact may not be identified, subsystem changes process can be very expensive when the servo controller
considered independent might lead to malfunction of the does not match well with the prototype system. It gets even
system as a whole because their impact is not evaluated worse when developing high precision machine systems."
appropriately. This is a clear example of how the solution space can be
--True global performance of the system cannot be restricted to one domain. In the example, the problem was
properly optimized because it is not considered when considered to be solved with the mechanical design. Only
performing a separate design for each domain. tests on the prototype show that the conceived controller
--Because the designers cannot keep track of the needs of could not perform properly in this design when it is too late
other designers, it is common to search solutions within the (i.e. when the problem cannot be managed by the
primary domain in use when problems arise in the middle of controller). If considered from the beginning, in numerous
the design of one of the subsystems. In that way, better cases the controller can compensate imperfections of
solutions that may come from other domains are systems from other domains, thus allowing to decrease
disregarded. manufacturing costs [1], including those of prototyping.
--Design of the controller does not receive enough
attention in the conceptual stages, leaving the solution of III. MODELING OF MECHATRONIC SYSTEMS
problems that presumably can be handled by the controller Models are crucial to support, communicate, and
for later design stages. This can increase the number of document the design activities. Partially, as a consequence
design iterations and the development time. of the current design practices that use a sequential and
It is clear that these problems can be surmounted by using domain-independent approach, existing modeling practices
the ideal, integrated, mechatronic approach for design for mechatronic systems follow the same approaches. Model
mentioned at the beginning of this section. Nonetheless, the types and modeling tools used in design are mainly
current design practices are far from reaching this ideal idiosyncratic. The choice of these models depends on the
design paradigm because of the implicit complexity present desired aspects of the system to be represented (or
in most mechatronic systems. There are several reasons that

388
simulated), and the level of detail to be specified. of the models) and the procedural integration (i.e.
These idiosyncratic modeling approaches (Fig. 2) become integration of the solvers) processes separately.
less effective as the complexity of the described system --Definitional integration becomes possible as models can
takes them to their limits. Other models and tools are be represented in a common language. A conversion of
necessary to overcome these limitations and obtain models external models to a common language is necessary.
that support effectively the integrated design approach. --Procedural integration may be more suitable for
II +12 = 13 situations where the models and their associated solvers are
-4 I1+ (-30) -5 I1 - lOll +60 +1012 =0 of diverse nature.
(a) --It is necessary to detect correspondence of variables
between models. This seeks to minimize necessary human
R=10o 4x intervention in the detailed levels of the model integration
E:3=60 V process. Typing schemes offer an alternative to aid in this
process.
R, =10 U
--Graphical user interfaces and views are crucial to
iki=-4 E2 0 =lz 20Vprovide model integration support.
--A single shared database that contains all the data of the
E =3 vV integrated models would quickly become a bottleneck.
(b) The concepts of reusability and modularity are also
Fig. 2. Mathematic (a) and graphic (b) models of an electric circuit important to model integration [13]. Using libraries of
(example taken from http://www.math.ucdavis.edu) "building blocks" for modeling is not only important to
A. Limitations of current models regarding complexity speed up the modeling and verification processes, but also
Models like the one in Fig. 2 suffice in cases where there opens the possibility of conceiving design support tools that
is need to represent a number of variables and aspects that is suggest gg ppossible solutions to the user.
still manageable to a human and analytical solutions are still IV. CASESTUDY
convenient. This is not the common situation for models
related to industrial products. For complex systems, models The main goal of the case study was to provide a proof of
like the one in Fig. 2 get hard to understand when numerical concept for automatic transfer of data between modeling
solutions require the use of concepts when difficult tools in different design domains. The case study required
interpretations or the use of large amounts of computational careful tracking of some specific design parameters from
power and time. The aforementioned problems associated their origins in the design requirements, following the
with complex systems reduce the efficiency of classical transformations along the design process (not necessarily in
models in terms of implementation feasibility and undermine that order), identifying transfer mechanisms and paths of
one of the main goals of models: assist humans to information flow. This tracking process for the case study is
understand the knowledge contained in the models. not relevant in itself for the present discussion, as the
Other source of complexity that complicates modeling is authors used it to observe aspects related to the processes of
the interaction of phenomena from different domains in the product design and controller design, and to the flow of
system. The existence of these interactions forces the information in such processes. This section exposes such
designers to "couple" models made in tools that, frequently observations. Originating from this work, the authors could
and in the first place, may not be designed to be compatible confirm the need of industry to have a support tool that eases
with each other. As a result, the coupling is performed, so to the transfer of information between modeling tools.
say, "manually" by the designers. The authors could identify how the development team
partially dealt with some of the aforementioned problems
B. Model integration to deal with complexity (sections 11 and lII). To design a product that uses several
It is agreed that a good way to deal with complexity of a new working principles (i.e. principles in which they possess
system is to describe the system at a high level (low little practical experience), first one or more functional
resolution) [9], trying to reach a concept of the whole. An models (FUMO) are developed. The FUMO consists of a
integrated modeling paradigm that gives the designers a system where one of the desired functions is achieved, and it
proper view of the system as a whole and in other levels of can be considered as a first prototype of a subsystem. With
abstraction, and that keeps track of the current needs [10] is each FUMO the designers gain enough experience to have a
fundamental to attain an integrated design paradigm that working version of a concept for a subsystem. Then, a
copes with the problems brought by complexity. In literature prototype (PROTO) of the product integrates the knowledge
it is possible to find basic concepts regarding model from the FUMOs. Developing PROTO the designers deal
integration ([10]-[12]): with the main integration problems between the subsystems.
--It is necessary to separate the modeler from the solver in After the PROTO stage is completed, the design of the
order to deal with the definitional integration (i.e. integration definitive series product can begin. In this last stage final

389
adjustments are made, and requirements that are related with
the production and trade of the product are considered in
detail.
Use of this design approach aims to attain greater product
quality (i.e. conformance to requirements) with less effort
(e.g. time, money, work), by acquiring knowledge in several
steps that deal with product complexity and increasingly
tighter specifications (see Fig. 3). A clear drawback of this
development approach is that it requires building a series of
intermediate prototypes, which require an important
investment of effort. The designer who described this design
approach to the authors mentioned that nowadays it is being
used less often (trying to use less prototypes and more
simulations) because the clients and the management
members seek avoiding the abovementioned disadvantage.
QualitY
Scn'es
PROTO _ Unlike the mentioned examples, the Automatic
FUMO / ---G- ----
Sngle step product development
Eflbrt
Fig. 3. Evolution of quality at different stages of product development
The authors also recognized a successful application of
mechatronic design closer to the ideal design approach
(section II.A) in the case study. The designers became aware
of the possibility to obtain high precision positioning of the
platform through an intensive use of control over all the six
degrees of freedom instead of relying solely on an extremely
rigid mechanical design. Relying only on the mechanical
design would require ensuring tighter manufacturing
tolerances than the positioning precision imposed by system
specification. The system not only achieved the required
precision, but also obtained an improved capability to isolate
the platform from vibrations transmitted through the base of
the machine.
Here is an overview of the design workflow in the project
of the studied case, used to approach a synergic design for
the domains involved in a mechatronic system. At the
conceptual stage, the design team members worked side by
side in close cooperation, in order to ease detection and
solving of problems related to their choice of an architecture
for the system (i.e. the chosen main working principles and
layout). Working "in close quarters" was necessary to
exchange information in a more efficient way. As the design
team grows to deal with details, this behavior becomes
unfeasible and information exchange has to be guided by the
team leaders. At this point they rely mainly on meetings and
written documentation to encourage information
interchange. Thus, most information is transferred manually.
As explained by the development engineers, the designers
390
often experience problems verifying the information
transferred manually as to keep it updated and free form
typing mistakes and unused data.
V. HIGH LEVEL MODEL INTEGRATION FOR CONTROL
DESIGN
The previous sections contain a review of the main
aspects and problems present in current design and modeling
practices for mechatronic systems. In previous works that
refer to those matters, two research branches can be
distinguished. One branch centers efforts in simultaneous
simulations concerning multiple domains (e.g. [3] and [1]).
These simulations rely on an accurate solution of a
mathematical model of the system, which is built almost
directly by the modeler. Another branch searches to provide
methods that enable evaluating the performance of the
system (e.g. [2] and [7]). These approaches seek a
theoretical background for decision making in design by
scoring how well a system achieves specifications.
Generation of Control Software for Mechatronic Systems
project attempts to advance on the front of model integration
and representation. Realizing that most of the design activity
in industry is performed using separate modeling tools (as
exposed in section III), one aim is to produce a framework
for containing a complete model of the system and provide a
mechanism of information exchange between modeling tools
([14], [15]). The authors of [11] comment that: "Another
area of integration that is becoming increasingly important
(...) for all applications is software integration. The ability
to link word processors, spreadsheets, databases, and
graphics packages in a seamless fashion enhances the
feasibility of modeling environments which can support
paradigm integration." In this way, designers can continue
using the available specialized modeling tools (which are
highly efficient in their own areas), but at the same time will
have the support of a framework to aid them to gather
updated information on other systems, export updated data
from their work, and view the existing design at different
levels of detail [10]. It must also be considered that
normally, detailed information is understood properly just
by the experts on a specific field, and that simulating a
model that contains such detailed information requires large
amounts of computational power.
A. The proposed approach
The propose th
The authors propose the use of a high level model of the
system based on a functional description to represent the
top-level conceptual hierarchy. This not only aims to give a
clear overview of the system, but also aims to act as a
skeletal structure that links models of lower levels of
abstraction. From this point of view the framework complies
with the meta-model paradigm [15]. The basic hypothesis
for this choice is that from the functional point of view it is
possible to describe a system in as much detail as needed,
focusing on the features of interest while maintaining models can correspond to single or multiple domains and to
coherence of the model as a whole. Functions act as different levels of detail. To form a consistent design at a
"wrappers" to the models, and as a result, domain certain stage, the models must correspond to each other by
distinctions become irrelevant at this level. In this manner, sharing certain parameters and their values. For example, at
the amount of information presented by the model can be some point in time the control engineer requires the mass of
controlled and inter-domain barriers disappear as needed. a part in order to simulate a simple dynamic model attached
The high level system model forms what we can call the to a controller model. At that point, the mass of the part can
system architecture (top of Fig. 4). The architecture contains correspond to a precise value calculated from a geometric
information developed mainly in the conceptual stage of model or to an estimated value laying in a database
design, which describes the functional principles of the corresponding to a parts list.
system. As the design develops, general functions are After obtaining a consistent model of the system,
decomposed into more concrete ones. We consider conformity of that model with the requirements can be
structuring this high level model following the Function- verified. This is achieved through comparison of the values
Behavior-State (FBS) approach proposed in [14] and [15], (or value ranges, and not necessarily quantitative) of the
though future extensions or modifications are expected. The evaluation parameters in the models to their desired values
high level model contains the necessary information to link specified by the requirements. Again, the link between these
the other models into a coherent model that represents the values lies in the functional structure contained in the high
whole design. This corresponds to: level model.
--The system requirements, related intimately with the If the values are changed with time and updated according
functional description, as to obtain traceability to all levels to the results in the models, it is possible to produce a
of detail in the model. simulation of the system. Of course, for doing that,
--Information related to model correspondence (i.e. the additional considerations like the choice of the time step
shared parameters). This is the manner in which the high must be taken into account.
level model acts as a mold that specifies in how the other Finally, though not related with functional modeling, it is
models are connected (i.e. which parameters are inputs or worth noting that an approach that shares several common
outputs for the models). Here we also find the criteria to aspects with the one exposed here can be found in the PACT
obtain a single value of a parameter when more than one project [10]. The main difference of both proposals lies in
model defines it. This can be done, for example, by the fact that in PACT there is no central shared model.
prioritizing the results of one model over the results of other Instead, it creates the impression of a shared design model
models or by specifying a weighed mean value from a group through interactions of agents and facilitators [10].
of results. This allows obtaining a coherent model of the
system by demanding a new iteration with a consistent set of B. Functional modeling
values or by running inverse models when available. This To give a better idea about the high level model used in
also sets a base for performing optimizations and targeting the proposed approach, next, a brief description of
specific values that conform to the requirements. functional modeling is given. Different authors have
System Arc~tecture proposed models, like Function-Behavior-State (FBS) ([14],
__________S__te____A_hitect _ _ lD [15]), Functional Representation (FR) [16], Schemebuilder
. Managemcorrespondence
~~~Manage cortMo6 dine_ [17], and MACE [ 18], which incorporate explicit knowledge
about functions of systems and devices. For a complete
_________________________ +review on functional modeling please refer to [19]. Though
Design>
Design I
A
..................
the proposals differ in several important aspects, some
common points are maintained:
Model I Model 2 --It is agreed that for modeling purposes the description of
Model 3 a function incorporates the intention of the designer or the
Model 4 given use of a device. Therefore, the definition of a function
is independent of the means used to attain it.
Design Model 1 --The state of the system is described in terms of the
Mdel 5 |values (qualitative or quantitative) of its state variables. A
MOdel 9 Modl 8 variable is linked to an object that makes part of a structural
X____________________________ ~description of the system.
--A sequence of state transitions for the system constitutes
Fig. 4. Diagram for proposed approach
On the lower part of Fig. 4, we represent the set of stages thexlnioofowheucinisaivd.IteFB
Of the design process. In each stage, the current state Of the reeecs(1]'1] hi skona eair
design~~ rersne.yasto
is odl Dsg rusi These models are not exclusively meant to represent
Fig. 4, e.g., 3D CAD model, block diagrams). Each of these fucinl "smpiie, knweg abu.h ytm hs
the definition of a function iS completed by complementing

391
it with information about how the function is accomplished
and which objects (including hardware, software, and
knowledge objects) are involved in this process. Most of
these modeling approaches define part of this knowledge
based on developments such as Forbus' Qualitative Process
(QPT),(PT),
Theory Theory dedeKleer
Kleer ad Brown's qualiative
and Browns rasoning
qualitative reasoning
theories, Kuipers' QSIM (see [20] for an introduction to
concepts of qualitative reasoning), and Bond Graph
represntatiotheory.
representation theor. The complete
omplee struture cn be ued
structure can used in
in
applications such as those mentioned in [19].
A possibility to be explored lies on the function's
potential potentialtocarythe
to carry the design
des1gn intention of systems,
1ntenhon of wh1ch
systems, which
could be used to guide or filter the results of a qualitative
reasoning process towards the interesting alternatives, thus,
increasing the potential of qualitative reasoning and naive
physics techniques. References [21] and [14] propose to
carry out the task of defining the function by using the
physical principles (or physical phenomena) that are
intentionally used to achieve the function; then, the
identified basic principles could be used to do some filtering
by choosing the results in which they appear in action.
VI. CONCLUSION
The authors consider that high level representations and
qualitative reasoning techniques have an intrinsic potential
to manage model complexity and to support simple and
efficient descriptions of system behavior. Then this can be
used as a first step in control code generation.
As the project goals are focused towards generation of
control software, the next stage of the research will focus on
definng the required correspondences between models that [13] A. M. Geoffrion,n"Reusing structured models via model integration,"
defining the required correspondences between models that
enable obtaining enough information about system behavior
to ensure controller performance. Also, it is necessary to
find*proermechnismst to te FSupport
link this inform
[14] T. Tomiyama, and Y. Umeda, "A CAD for functional design," in
n
architecture.
It must be identified what level of proficiency and [15] T. Tomiyama, T. Kirayama, H. Takeda, D. Xue, and H. Yoshikawa,
knowledge of the system is required to build an appropriate
high level model and maintain it.
The authors do not pretend to use the studied design case
as a general model of current design practices. Even within a
company, design practces change between different projects
and different design teams/leaders. The case is presented as
a representative example of what can be found as a design
practice In the Industry of mechatronic products
development.
ACKNOWLEDGMENT
The authors wish to thank Mr. M. Beekveld, Mr. P.
America, and the rest of the
America, the engineering team
and the rest of team from
engineering Philips
from Philips
Applied Technologies, for providing the industrial case
study and their enthusiasm for this work.
REFERENCES
[1] J. van Amerongen, "Mechatronic design," [online] in Mechatronics,
Vol. 13, Issue 10, December 2003, pp. 1045-1066.
[2] Y. Xu and H. Zou, "Design principles for mechatronic systems based
on information content," [online] in Proc. IMechE, Vol. 221, Part B,
pp. 1245-1254, March 2007.
[3] G. Avigad, A. Moshaiov, and N. Brauner, "Towards a general tool for
mechatronic design," [online] in Proceedings of 2003 IEEE
Conference
1035- 1040.
on Control Applications, 2003, CCA 2003, Vol. 2, pp.
[4] C. Zielifiski, W. Szynkiewicz, K. Mianowski, and K. Nazarczuk,
"Mechatronic design of open-structure multi-robot controllers,"
[online] in Mechatronics, Vol. 11, Issue 8, December 2001, pp. 987-
1000.
[5] K. Craig, M. De Vito, M. Mattice, C. La Vigna, and C. Teolis,
"Mechatronic integration modeling," [online] in International
Conference on Advanced Intelligent Mechatronics, 1999.
Proceedings. 1999 IEEEIASME, Sept. 1999, pp.1032 1037, Atlanta,
GA.
-
[6] D. A. Bradley, "The what, why and how of mechatronics"' in
Engineering Science and Education Journal, Apr. 1997, Vol. 6, Issue
2,pp. 81-88.
[7] R. X. Lu, C. W. de Silva, M. H. Ang Jr., J. A. N. Poo, and H.
Corporaal, "A new approach for mechatronic system design:
Mechatronic design quotient (MDQ)," [online] in Conference on
Advanced Intelligent Mechatronics, Proceedings, 2005 IEEEIASME
International, July 2005, pp. 911-915, Monterey, CA.
[8] J. Y. Yen, and R. J. Lee, "A solid modeling based mechatronics
approach to machine tool servo design," [online] in Proceedings of the
2004 IEEE International Conference on Control Applications, 2004,
Vol. 1, pp. 730 - 735.
[9] J. Rasmussen and M. Lind, "Coping with complexity," [revised
reprint.] presented at the European Conference on Human Decision
and Manual Control, 1981, Delft, The Netherlands. ISBN 87-550-
0769-4 ISSN 0418-6435.
[10] M. R. Cutkosky, et al, "PACT: An experiment in integrating
concurrent engineering systems,"[online] in: Computer, Jan. 1993,
Vol. 26, Issue 1, pp. 28-37.
[11] D. R. Dolk, "An introduction to model integration and integrated
modeling environments," [online] in Decision Support Systems,
Volume 10, Issue 3, October 1993, pp. 249-254.
[12] D. R. Dolk, and J. E. Kottemann, "Model integration and a theory of
models," [online] in Decision Support Systems 9(1), pp. 51-63.
[online] in Proceedings of the Twenty-Second Annual Hawaii
International Conference on System Sciences, 1989, Vol.111: Decision
and Knowledge Based Systems Track, pp. 601-611.
Annals of the CIRP'93, Volume 42, No. 1, 1993, pp. 143-146.
"Matamodel: A key to intelligent CAD systems," [online] in Research
in Engineering Design, Vol. 1, Number 1, March 1989, pp. 19-34
[16] B. Chandrasekaran, "Functional representation: A Brief Historical
Perspective," in Applied Artificial Intelligence, vol. 8, pp. 173-197,
1994.
[17] R. Bracewell, and J. Sharpe, "Functional descriptions used in
computer support for qualitative scheme generation -
"Schemebuilder"," in AI EDAM Journal - Special Issue: Representing
Functionality in Design, Vol. 10, 1996, pp. 333-346.
[18] J. Hunt, "MACE: A system for the construction of functional models
using case-based reasoning," in Expert Systems with Applications,
Vol. 9, Issue 3, 1995, pp. 347-360.
[19] M. S. Erden, H. Komoto, T. J. van Beek, V. D'amelio, E. Echavarria,
and T. Tomiyama, "A review of function modeling: Approaches and
applications,' in Artificial Intelligence for Engineering Design,
Analysis and Manufacturing, Vol. 22 , Issue 2 (January 2008)pp. 147-
169.
[20] A. Barr, and P. R. Cohen, "The Handbook of Artificial Intelligence,"
Vol. 4. Chapter 21. Los Altos, CA: William Kaufmann, Inc. 1989.
[21] V. Akman, P. J. W. ten Hagen, and T. Tomiyama, "A fundamental and
theoretical framework for an intelligent CAD system," in Computer-
Aided Design archive, Volume 22, Issue 6 (July/August 1990), pp.
352-367.
392