Saginaw, MI 48601. Ronald C. ... Michigan State University. East Lansing, MI ..... One is by keyword; one is by constraint type, and one is by generation history.
Published in: Proceedings ASME IMECE 2000 DSC- Vol.69-2, 787-794
STRUCTURED MODELING OF MECHATRONIC COMPONENTS USING MULTIPORT TEMPLATES Michael K. Hales Delphi Automotive Systems 3900 Holland Road Saginaw, MI 48601
ABSTRACT Mathematical modeling of mechatronic systems is increasing in its importance to industry for product development. Mathematical modeling helps companies reduce the lead time for new product development, allows for consideration of more design alternatives, provides a means for capture of engineering knowledge, and facilitates sharing of engineering efforts with suppliers. Structured modeling further assists engineers in meeting these goals by supporting effective, clear communication of model information. This paper describes a modeling environment for mechatronic system design based on structured modeling concepts. Structured modeling is implemented using a multiport template approach. A multiport template allows the engineer to create new user-defined model types, which are in turn used to create computational instances. The focus is on mechatronic component modeling. Illustrations of the method are given. 1 1.1
INTRODUCTION
The need for structured modeling Engineers in industry who are responsible for new mechatronic product development are increasing their use of mathematical modeling. There are several reasons for this trend. One reason is the need to decrease the time it takes to bring a new product to market. A second reason is the need to consider many design configuration options, in numbers far exceeding what a hardware testing program could expect to accomplish at reasonable cost in reasonable time. A third reason is the need to engage suppliers in a close relationship at the design development stage, which requires a clear method for negotiating and following up on design responsibilities of the several parties involved. A fourth reason is the need, increasingly recognized by companies, to improve returns on modeling investments. They would like to realize continued benefits by developing models that are reusable by many engineers over a significant period of time and for a number of product development projects.
Ronald C. Rosenberg Department of Mechanical Engineering Michigan State University East Lansing, MI 48824
A critical factor in developing a model knowledge base that has the potential to address the needs outlined above is the use of structured modeling. Structured modeling organizes model information such that it is accessible and available to a wide range of people, well beyond the immediate circle of initial model developers. Despite companies' legitimate concerns that making their product model database widely available could benefit their competitors, it is nonetheless more costeffective to develop useful databases and then deal separately with the problem of access control. 1.2
A Template-based structured modeling approach In this paper we address the issue of building a structured model database for mechatronic components using a multiport template approach. Since mechatronic components typically include a variety of energy domain effects, closely coupled with information subsystems for control, the modeling method must support these aspects in an intuitive manner. The multiport model approach does provide this support. The template feature makes it easy for a user to understand the several classes of information involved in defining a multiport mechatronic component, and it enables the design and implementation of an effective user interface. Many of the ideas we have used in this work have been developed by others interested in some aspects of the problem we have outlined. Since multiport components are concerned with both energy transfer and information transfer, modeling methods that deal effectively with energy transfer, transformation, storage, and dissipation processes are especially useful. In particular, the power-based modeling concept introduced by Paynter [1] in the form of bond graphs has proven to be valuable. Many others have developed and advanced bond graph modeling methods, such as Breedveld[2], Cellier[3], and Karnopp, et al.[4]. Formal multiport component and system modeling constructs have been developed by Rosenberg, et al [5], Otter and Cellier [6], and Elmqvist, et al. [7]. Structured modeling was discussed in relationship to model types by Vries [8], in relationship to proper model development by Stein and Louca [9], and in relationship to model
libraries by Breunese et al. [10]. Particular concepts related to hierarchical model representation in a multiport context have also been explored, by researchers such as Cellier [11], and Hales [12]. This brief set of citations is intended to be representative, not encompassing, since the field is broad and the number of contributors is large. 1.3 Design considerations for a structured modeling environment There are a number of features that are desirable for a good modeling environment. One feature is that use of modeling tools should be "intuitive." That is, the patterns used by the designer when trying to mapping the physics into the model environment should be supported by the design environment as naturally as possible. A second feature is that simple models should be easy to create and edit. While more complex models would require a more complex set of tools and have a steeper learning curve in order to achieve mastery, advanced features should not interfere with standard use. A third desirable feature is that as many model creation errors as possible should be prevented instead of detected. To some extent this feature is not widely appreciated, except in its absence. There are other important desirable features of a design environment that we will not discuss in this paper, but which are compatible with the approach taken here. These features include support for building and using a well-organized library of models and support for controlling access to models and their details by specific classes of users. The latter feature addresses the need that was outlined earlier regarding a company's need to control access to some of its model knowledge base by particular types of users. A flexible modeling environment provides for creation and manipulation of a rich set of working models. One approach in designing a modeling environment is to provide considerable generality. In this instance one must provide general modeling tools. For example, a language like C++, together with an object library and a language compiler, constitutes such a general modeling tool. Negative aspects of this arrangement include both the difficulty of learning how to use the tools to create effective models of complex situations and the lack of meaningful support tools to ease the tasks of model creation and maintenance. At the other end of the spectrum is a modeling environment that is very specific, with obvious iconic tools well suited to the model domain. There are many examples of such environments; some specialized for circuit design, some for design of rigid-body mechanical systems, and some for design of fluid power systems. A drawback of this type of environment is that the range of models that can be defined is limited. It is our goal to present an environment for mechatronic component modeling that achieves a good balance between the two types mentioned above, being neither so general that useful modeling support is lacking nor so specialized that the user must live by an unacceptable set of modeling constraints. Our approach is based on the concept of model types. A model type consists of rules, definitions, and attributes describing a class of models. Model types are not computable entities, but are rather used in creating model instances, which are computable. The concept of model types is further extended to include User-Defined Model Types
(UDMTs). UDMTs provide a means whereby the user can customize the modeling environment with a set of her or his own model types that are most useful to her or him directly and to the associated design group. It will be seen that model generation time can be decreased because, instead of starting from scratch each time a new system is to be modeled, an engineer can browse a library of existing UDMTs for ones that most closely meet current needs. UDMTs also serve as a repository of modeling knowledge; efforts and knowledge used to solve previous problems become resources available for solving future problems. The amount of flexibility the environment should permit to a user for modifying properties of a model instance created from a UDMT is not universally agreed upon. Current implementations tend to fall at one of two ends of a spectrum. At one end, allowed modifications are very limited, perhaps restricted to modification of a set of parameter values. The underlying structure and equations remain invariant. Such limitations help to ensure that a particular model instance created from a UDMT is not modified in ways inconsistent with its intended definition. However, it severely restricts the useful forms that it can take and tends to lead to the creation of many closely related UDMTs. At the other end of the spectrum, modifications of the properties of an instance created from a UDMT may be relatively unlimited. This approach allows for more efficient use of a UDMT but it can lead to inappropriate model instance creation. Figure 1 illustrates such a situation. A default instance of a 1-Port C-Type component is shown in part (a). Assume that the user is able to modify the component equations to the form shown in part (b), and he does so either through ignorance or error. The component can be fitted into a system model, but the behavior will not be that of a C element; it will be that of an R element. e f
C
e f
C
q = ∫ f dt e = q/C
q = ∫ f dt e=f· C
(a) Default
(b) Improperly Modified
Figure 1. Modifying an Instance of a 1-Port, C-Type. Another difficult issue in working with UDMTs arises when one wants to create a new UDMT. Normally one starts with a "blank slate" every time a new UDMT is needed, even if the new model type is only slightly different from an existing one. A third issue involves the classification of UDMTs. When a large number of UDMTs have been defined, a clear and convenient ordering and a method for finding a model with desirable characteristics are imperative. Most commonly, model classification tools are limited to grouping model types according to some criterion such as model "purpose" or "functionality." While this approach can be effective, it has weaknesses. One weakness is that the location of a particular model type is a rather subjective decision. Two different users may place the same model in different model groups. Another weakness is that the method relies on a model
Our Approach To address the issues raised above, a new environment for defining User-Defined Model Types for mechatronic components was designed and implemented. This paper discusses the design and shows how it improves on the way in which UDMTs can be defined, created, and classified. The goal is accomplished by permitting the creation of UDMTs based on three attributes. These are (1) a basic modeling structure called a General Multiport; (2) a set of constraints that specify the range of properties that the UDMT can have and that bound the values the properties can assume; and (3), and a set of default property values. Interface editors that work with a Multiport Template (hereafter referred to simply as a Template) govern the interaction of the user with the features of a UDMT. The Template is the information structure used as the basis for creating instances of a given UDMT. The novel feature of our environment is the way in which the user can create new Templates for component types and the relationships that result among Templates thus created. The Template information is closely related to the kinds of information that a user must define for a mechatronic component model in any form, thus leading to an intuitive coupling. The balance of this paper is organized as follows. Section 2 describes the properties of a General Multiport. The Template design is given in Section 3. The usefulness and effectiveness of the design environment is demonstrated by two examples in Section 4. Finally, Section 5 presents a summary. 2
THE GENERAL MULTIPORT COMPONENT
2.1
Basic features The information structure called the General Multiport establishes the range of UDMTs, and hence the model instances, that can be defined in this environment. Such a definition represents our best judgement of a suitable level at which to underpin the modeling environment. The definition provides a foundation for building models of many mechatronic components, and it is designed in such a way that it can be generalized within the overall structural framework in the future. The definition of the General Multiport is organized into four categories. These are the Topological Properties, the Functional properties, the Parametric properties, and the Display properties. 2.2
Topological Properties Figure 2 shows a representation of the General Multiport Component. All other UDMTs in the environment are derived either directly or indirectly from this object. The General Multiport can be instanced directly, although this is an inefficient way to use the environment.
Parameters: p:{ p1, ..., p j}
...
... sn
...
1.4
Power Ports e1, f1
Component
...
Signal Ports s1
being assigned to a "correct" group. If a model is placed in an improper location, it could be hard to find, or worse, it could give an incorrect impression of the model's purpose and implied behavior.
em, f m
Figure 2. The General Multiport Component. The topological properties include the multiport Component itself, a set of power Ports, and a set of signal Ports. The Ports are directly associated with the Component. A power and signal Ports may be directed in or out, relative to the Component. A Port indicates a site for interaction of the Component with its environment. Ports can be physically meaningful, e.g., a rotating shaft, or purely functional, e.g., an input signal to a transfer function. At the system modeling level two like Ports, normally belonging to two different Components, are associated by a Connector. In this paper we do not discuss the system aspects of the design environment. 2.3
Functional Properties From a system perspective a Multiport Component has two types of variables: inputs and outputs. The output set in terms of the input set defines the functional properties of the Component. Two constructs, Port Variables and Equations, capture the functional properties of the General Multiport. 2.3.1 Port Variables. One or more Port Variables are directly associated with each Port. In our modeling environment all Port Variables are scalar and dynamic; that is, they are functions of a continuous time variable. A Signal Port has a single variable as its Port Variable. According to the direction at the port, the variable is a functional input or output to the Component. This is of course congruent with the definition of block diagram components. Two Port Variables are associated with a Power Port. Generically these are designated as e for effort and f for flow, but the port power domain type actually sets the specific variable types. For example, a shaft port has the variables τ for torque and ω for angular velocity. The product of the two port variables gives the instantaneous power. The direction of a Power Port indicates the positive direction of power. At a Power Port one of the variables is taken as the functional input and the other is taken as the functional output. This association may be fixed by the nature of the Component; e.g., an electric battery model normally has the voltage at its port defined as the output. Alternatively a Component may be "indifferent" at a power port; e.g., a finite linear electrical resistance could be characterized in terms of the current in (and voltage out) or the voltage in (and current out). Expression of such properties is done through setting of Causality at a power port. Other researchers, such as Breedveld [2], Van Dijk [13], and Breunese [14] have defined additional Port Types, such as vector power ports. They will not be considered further here. However, the design presented here does not preclude future definition of other Port Types and their associated variables and functional properties.
2.3.2 Equations. Equations are expressed in terms of Constants, Parameters, Port Variables, and Internal Variables. The Internal Variables associated with a Component are not accessible outside the Component. Equations may be expressed in traditional mathematical form (e.g., algebraic and differential) or expressed as logic statements and procedures (e.g., if-then statements and loops). We point out here an issue that is operative at the system level. At the system level a Component may be one of two types, as illustrated in Figure 3. A Core Component is directly associated with Equations and is structurally irreducible. A Subsystem Component is a connected assembly of other Components, supporting hierarchical model descriptions. The Equations of a Subsystem Component are implied, being derivable from the contained Core Components. Whether a Component should be created as a Subsystem or as a Core depends on modeling judgement. For example, a multiport model of a DC motor could be realized either by an assembly of basic Components such as resistors, inductors, inertias, etc., or by an explicit set of Equations. Core
Subsystem
Equations
Figure 3. Core and Subsystem Multiport Components. Equations in this system are treated symbolically. This feature is important for supporting reusable models, as pointed out by Cellier and Elmqvist [15]. One reason this is true is that, using the connection scheme defined above, symbolic equations are required to accommodate Components that have system-dependent causality. That is, a Component equation may need to be inverted so that a particular port variable is the output, to meet system formulation needs. For other connection schemes, it is possible to avoid equation reformulation, as was demonstrated by Byam [16]. 2.4
Parametric Properties It is often useful to define a set of Parameters for modeling convenience. Parameters may be physically meaningful, such as material properties or dimensions. Definition of common symbolic constants, such as π, may also be useful. A Parameter can be associated with a Multiport in several different ways, depending on its intended use. A Parameter associated with a System is considered "global" and is accessible to any Component that is contained in the System. Two examples are the density of a hydraulic fluid and the ambient temperature. It might also be desirable to have a Parameter that is only accessible to a subset of a system's Components. In this case, a Parameter should be associated with a Subsystem Component. When a Parameter should only be accessible to a single Component, then the Parameter should be associated with a Core Component.
conveniently locate, refer to, and classify Components. It is important that the ideas suggested by a Component's display properties be consistent with the Component definition. Such consistency is important because users who may be unfamiliar with the particular system model often heavily rely upon the Display data. A good implementation that relies on Component display properties can be useful when one is browsing or searching the contents of a large Component library. For example, if models with similar purposes are grouped according to Keywords, then finding a model for a particular purpose at hand can be greatly simplified, as noted by both Breunese et al. [10] and the OLMECO project [17]. Finally, the display Icon serves a practical role in a Graphical User Interface (GUI) for selecting, graphically manipulating, and editing a system model's properties. 3
TEMPLATES FOR MULTIPORT COMPONENTS
3.1
UDMTs and instances In this modeling environment there are two distinct types of Component modeling activities. The first is the relatively familiar activity of using an existing UDMT to create a new Component model Instance. This is a capability that most good modeling environments now provide. The second is the activity of creating a new UDMT, based on an existing UDMT. 3.2
Creating new Component Instances Figure 4 shows the relationships among an Instance, a Template, and a User. A Template is our implementation of a UDMT. The User instantiates a model component (that is, creates a specific working model of a model component) by selecting the desired Template. An Instance Editor guides the User in editing the attributes of an instance. The particular Template also "tunes" the editor so that it is as intelligent as possible. This arrangement provides one way to minimize instancing mistakes by the User. Provided that the User is familiar at least to some extent with the modeling concepts that underpin Multiport modeling of mechatronic systems, then the editor will appear to be very intuitive. As we discuss in the next subsection, once the user is familiar with the process by which a new Template is derived from an existing Template, the use of a Template for instancing is simple. A Template contains enough information to create a valid default instance, so a naïve user can create valid instances readily. Multiple Instances can be created from a single Template; each Instance maintains its own attribute data. Often there are some properties of an Instance that can be examined by the user, but not modified. Also there are limits on how some properties can be modified. The Editor facilitates the implementation of these features. Instance Editor View
User
Tune
Model Instance
Instantiate
Template
Modify
2.5
Display Properties A Multiport's display properties include Icons, Name, and Keywords. These properties serve as mnemonics to quickly and
Figure 4. Working with an Instance and a Template.
3.3
Creating new Component Templates The real power of the modeling environment comes from the process of creating new Templates for new UDMTs. Figure 5 shows the relationships among the User, an existing Template, and a new Template. The critical feature is that a new Template is achieved by deriving it from an existing Template. Type Editor View
User
Tune
New Template
Derive
Existing Template
Modify
Figure 5. Creating a new Template. In order to realize a new UDMT in the modeling environment the User selects an existing Template as the basis. The existing Template contains data that "tunes" the Type Interface, so that the User is guided through the creation process in an intelligent fashion. The new Template is derived from an existing (or "parent") Template by imposing additional constraints, as described below. A Template coordinates three sets of data. These are (1) The General Multiport Definition. All Templates are based on this definition, which bounds the range of models that can be defined using a Template. (2) Constraints. A given Template contains a set of Constraints that are used to specify allowable properties of the General Multiport that define the current UDMT. (3) Default Property Values. A Template contains a default set of model property values suitable for defining a valid Instance of the UDMT. The unique feature in this design is the use of Constraints to specify a UDMT's properties. We think that this approach is congruent with "top-down" modeling thinking, in which a more general model is restricted in order to realize a simpler version. This method is different from many other implementations of UDMTs, which specify a set of associated properties. The constraint set also helps users other than the creator of the Template to see what was intended. In this way it is easy for others to use an existing UDMT that they did not create as the basis for a new UDMT, expressed in Template form. Additionally, the Constraint set is used to tune the Template editor. Now consider the steps required when deriving a new Template. There are two types of action a user takes. First, the user defines additional Constraints to be applied to the parent Template. Second, the user defines additional default property values. A brief example will help to illustrate these ideas. Consider again the 1-Port C-Component shown in Figure 1 and the three aspects of a Template discussed above that would be needed to define this Model Type. General Multiport Definition. The properties of the General Multiport Component are sufficient to support the definition of a 1Port C-Component. Constraints. The following constraints prescribe the way instances of the C-Component can be modified. • The C-Component must have exactly one Power Port. This constraint means that no other Ports can be added and the default
port cannot be deleted. Note that the power direction may be in or out; it has not been restricted in this particular UMDT definition. • The first component Equation is "fixed": dq/dt = f. That is, the user can view this equation, but cannot modify it. • The second component Equation has the fixed form 0 = φ(e q). That is, only the port variables e and q can be used to define this equation. • The port variable e is "preferred" as an output. This constraint suggests to the user (but does not require) that the second component equation specifies e as the dependent variable. Default Property Values. The following information specifies a default instance of the C-Component. • The Port direction is in. • The second Equation is defined as: e = q/C. In this equation C is in the p list and may be given a default value. 3.4
Working with Templates. To facilitate the derivation of new Template creation, a special non-derived Template, called the General Multiport Template is defined as part of the environment. This Template has no constraints and no default values. Any model instance created from the GMT can be configured in any way supported by the General Multiport definition. If the user wants to create an instance of an existing UDMT, he or she selects the Template that defines the UDMT. An Instance of a working model is created having the default property values. The Instance Editor interprets the Constraints and enforces them, thereby allowing the user modification access only to those properties that are not fixed by the Template. The user can always select the General Multiport Template and engage in a relatively lengthy dialog to set all of the necessary properties of the desired UDMT instance. If the user decides that a target UDMT requires the definition of a new Template, then a different editor is activated. An important decision for the user to make is to select an existing Template to serve as the "parent", since every new Template is derived from an existing Template. The new Template inherits the Constraints and the default properties that have fixed Constraints from the parent Template. The parent-child relationship between Template pairs and the inheritance of constraints sets up a unique and useful structuring of model information. First, a collection of Templates will have a tree structure relation as illustrated in Figure 6 (a). A Difference between Templates in the tree is the number and type of constraints that have been applied to them. This fact implies another structuring model information. In Figure 6 (b) each oval represents an instance space, or the range of possible instances that may be created from a given Template. The instance space of any Template is a strict subset of the instance space of the Template's parent. The subset nature of the Template ordering also orders the instances created from them. For example, Template T1 has fewer constraints than Template T2; therefore, instances created from T1 have greater editing flexibility than instances created from T2. Instances created from T2 require less editing.
Add Constraints
General Multiport Template
T1
T2
Template 3
General Multiport Template Template 1 Template 2
T3 (a) Derivation Tree
(b) Possible Instance Configurations
Figure 6. The Parent-Child Relation among Templates. As stated previously, the General Multiport Template contains no Constraints or fixed default values. The GMT can be used as the parent of every other Template a user might wish to create. In that case, the relationship structure of the template family will be very broad and one layer deep. This structure implies that no meaningful relationships among the templates exist. 3.5
Template Libraries. Many commercially available modeling environments currently provide a large number of pre-defined model types for specialized purposes. Models are often organized into groups according to their purpose or their power domain. Models are listed in the library by a name and/or an icon. For example, Easy5 from Boeing [18] has such a model library architecture. Each group of models is referred to as a "library." Some Easy5 libraries are the "Valve and Actuator Design Library", the "Electric Drive Library", and the "Aerospace Vehicle Library." When a new UDMT is created in this environment, it can be placed in any pre-existing library or in a new library specified by the user. If a large number of UDMTs have been created and stored in a set of libraries as described above, then searching for a particular type of model may be cumbersome. One must select an initial library and then browse through a long flat list, typically arranged alphabetically. This observation is especially true if someone is using the set of models other than the one who created most of them. Breunese, et al. [10], addressed some limitations regarding model libraries. They defined a classification scheme that permits models to have multiple classifications. Again, if the number of models within a given classification becomes large, the original problem of sorting through a long flat list of models remains. One benefit of the parent-child Template structure is that at least three methods for organizing a list of Templates are possible. One is by keyword; one is by constraint type, and one is by generation history. These methods help to overcome the library problems listed above. A brief description of these methods is given below. Organization by Keyword. Recall that part of a Template definition includes a set of keywords. By thoughtfully associating a set of keywords with the Templates in a library, a simple yet powerful sorting mechanism can be employed for searching through a list of Templates. Keywords allow a set of Templates to be classified in multiple ways, not just placed in a single group. It also means that it is possible to find a Template in a Library in multiple ways. Organization by Constraint. The idea of using keywords as a filter can be extended to using the Constraints that are associated with a Template as a search filter. For example, a library could be searched
for models that have the Constraint that no Power Ports are allowed, or for models that are constrained to have only Algebraic Equations. Often such an approach is congruent with the way in which an engineer might think about a particular component. An additional advantage to constraint searching is that the Constraints associated with a Template directly influence its functionality. That is, the Templates found from a Constraint-based search are guaranteed to exhibit the behavior specified by the Constraints. One weakness of this scheme is that the list of constraints on which to search is limited to the types of Constraints defined in the environment. Also, the Constraints are strictly limited to functionality; abstract classifications that are possible using Keywords are not possible. Organization by Generation History. A third classification scheme takes advantage of the Parent-Child relationship between Template pairs. The ordering of Templates in a tree structure means that neighboring templates have a generally known relation of their properties. For example, if a candidate model located in a library is too general, then searching in the child Template neighborhood might efficiently yield good results. Conversely, if a candidate model is too restrictive, perhaps a model in its parent neighborhood will be appropriate. By combining several search methods in a directory-structured library, great efficiencies in finding useful models should be possible. The directory structure will reflect the thinking of the person(s) who built it. For example, consider the task of initializing an environment library with a set of electrical components that only have Power Ports. One way to do this is first to define a Child Template of the GMC that adds the single constraint that all the power ports must be electrical. The next step is to define a new Child Template with the added constraint that there are no Signal Ports. This path is illustrated in Figure 7(a). Another way, perhaps equally likely, for obtaining the same results would be first to define a Child Template of the GMC having no Signal Ports and then to use this Template to define a new Child Template that adds the Constraint that all Ports are electrical. This path is shown in part (b). If the library offers some clues, perhaps through keywords, as to which path was used, then efficient browsing would be enhanced, because the underlying thought patterns would be understood by the browser. General Multiport
General Multiport Electrical
No Signals
Electrical, No Signals (a) Path 1
No Signals, Electrical (b) Path 2
Figure 7. Two Paths for Generating a Template. 4
ILLUSTRATIVE EXAMPLES Two examples will help to illustrate how the design ideas discussed in this paper are used when working with Templates. The first example demonstrates how a Template is used to define and work with an instance. The second example shows how new Templates are
4.1
A DC Motor model. As the first example consider a UDMT described as a permanentmagnet dc motor (PMDC Motor). The Template data is shown in Figure 8. Recall that the Template data is not used directly in a model for computational purposes. Rather, the Template data is used to create model instances that are in turn used computationally.
Component Type Core Ports Electrical Power In Rotational Power Out Functional
Port Variables v, i Electrical: Rotational: τ, ω Equations 0 = vL + vR + vm - v 0 = τm - τJ - τR -τ vm = kmω τm = kmidi vL = L dt
vR = R ei τ J = Jω& τR = R mω Parametric
Parameters p = {km, Re , L, J, R m}
Display
Icon Key Words Two Port, Transducer,... Name PMDC Motor
Constraints
Fixed. Fixed Port Number. Fixed domain, direction. Fixed domain, direction. Constraints
Prefer v as input. Prefer τ as input. Allow ODE and Algebraic. Fixed. Fixed. Fixed. Fixed. di 0 = φ5 (v L , , p) dt
0 = φ6 (vR, i, p) 0 = φ 7 (τ R , ω& , p) 0 = φ8 (τR, ω, p) Constraints
km∈{km 1, km2, ..., kmn} Re,min ≤ Re ≤ R e,max L = Lmotor Jmin ≤ J ≤ Jmax 0 < R m ≤ R m,max Constraints
Fixed.
Fixed.
4.2
Creating and Classifying UDMT Templates. When creating a new Template, the starting point is either the General Multiport Template or another existing Template. Consider the process of defining new Templates as illustrated in Figure 9. Our objective is to create some functional input-output components for use in block diagram models.
Fixed.
Figure 8. A Template for a PMDC Motor. The information in Figure 8 is organized into the four categories that were used to describe a General Multiport in Section 2. In the lefthand column default property values are given. Constraints are listed in the right-hand column. The data in the two columns are correlated by row. The topological property "Component Type" specifies the default value as "Core". This means that the Component is structurally irreducible; its Equations are associated directly with the Component. A Constraint on this property specifies that the "Core" designation is Fixed. This Constraint indicates that a user creating an instance cannot change the Component Type from Core to Subsystem. The Ports default data also restrict all instances to have exactly two power Ports, one Electrical with power in and one Rotational with Power Out. The Functional section deals with equations. There are four port variables, two of which must become component inputs, while the other two must become outputs. One input and one output must be associated with each port. The preferred form of the Component
General Multiport Template
C1
x
...
Topological
equations is for v and τ to be inputs and for i and ω to be outputs. The default Equations are listed in the left-hand column. The first four equations are fixed; they can be viewed by the user but not edited. The next four equations are given in linear form, but the constraints indicate the general nonlinear forms that can be assigned by the user. The detailed equation set indicates that the electrical inductance and resistance, as well as the mechanical inertia and friction, are included. The back emf of the motor is also included. It is significant that the default equations listed are "true" equations; i.e., they are not a set of assignment statements. This feature makes the PMDC motor model more portable and less dependent on its use is a system. When the model is placed in a system and the input/output requirements are known, the modeling environment symbolically manipulates the equations appropriately. The Parametric section identifies the set of supporting parameters for the equations. Two types of Constraints on Parameters are illustrated. The motor constant k m has a set of allowable values. The motor inductance L has a fixed value. The other three Parameters have an allowable range of values. The data of the Display section are quite obvious. Member of the Key Words list should be thoughtfully chosen; a brief indicator is given in the figure. The Instance Editor enforces the Constraints specified in the Template. All items defined as "Fixed" can be viewed but not edited by the user. This feature preserves the intended core behavior of all instances of the PMDC Motor, as defined by the creator of the Template.
Add Constraints
T1
y = f (x)
...
created based on existing Templates and the natural classification that arises.
y
x1 x2
C2
T2
C3
y x1 x2
T3
y
y = f (x1, x2)
y = p1x1 + p2x2
Figure 9. Deriving a New Set of Templates. A new Template, T1, is derived from the General Multiport Template. The Constraints C1 are as follows: no Power Ports; 1 to n In Signal Ports; 1 to m Out Signal Ports; and Algebraic Equations. Such a component is useful for modeling general nonlinear signal transformations. A new Template, T2, is derived from T1. Constraints C2 add the requirements that there be exactly one Signal Out and exactly two Signal In Ports. This means that model instances based on T2 have less
flexibility than models based on T1, but they can be created more efficiently, with less likelihood of error, for specific tasks. A new Template T3 is derived from T2. Constraints C3 restrict the Equations to be Linear. T3 represents a Weighted Sum Block, with the parameters p1 and p2 accessible to be modified by the user. Note that the Templates T2 and T3 each could have been derived directly from the General Multiport Template. However, this approach would require more input effort from the user than the path shown in Figure 9. Furthermore, there would be no evident relationship enforceable by the environment among the three new templates. The path above leads to a "natural" classification, in terms of the way many users might think of these three UDMTs.
8.
5
12.
SUMMARY In this paper we describe a design for a modeling environment that supports definition and use of User-Defined Model Types (UDMTs) of mechatronic components. A general modeling structure, called a General Multiport, is presented which defines the range of possible models that can be built. The definition is sufficiently general to allow for definition of a large class of practical engineering models. A Multiport Template was described which represents a new method for defining UDMTs by combing the General Multiport definition, constraints that prescribe the range of model instances that can be created from a given model type, and default property values for creating instances of a UDMT. This unique structuring of information makes it possible to (1) bound the allowable configurations of instances of a UDMT; (2) derive new UDMTs based on existing model types; and (3) structure and classify a set of UDMTs according to functionality and purpose.
9.
10.
11.
13.
14.
15.
16.
17.
The design benefits were demonstrated using two examples. 18. 6 1. 2.
3. 4.
5.
6.
7.
REFERENCES Paynter, H.M., 1961, Analysis and Design of Engineering Systems, MIT Press, Cambridge, MA. Breedveld, P.C., 1985, "Multibond graph elements in physical systems theory.", Journal of the Franklin Institute, 319(1/2), pp. 1-36. Cellier, F.E., 1991, Continuous System Modeling, Springer-Verlag. Karnopp, D.C., Margolis, D.L., and Rosenberg, R.C., 1990, System Dynamics: A Unified Approach, 2nd ed., Wiley Interscience, New York. Rosenberg, R.C., Hales, M., and Minor, M., 1996, “Engineering Icons for Multidisciplinary Systems”, Proceedings ASME Dynamic Systems and Control Division, DSC-Vol.58, 665-672. Otter, M. and Cellier, F., 1996, "Software for Modeling and Simulating Control Systems", The Control Handbook, CRC Press, Boca Raton, FL, pp. 415-428. Elmqvist, H., Mattsson, S.E., Otter, M., 1998, "Modelica - An International Effort to Design an Object-Oriented Modeling Language", Proceedings of the 1998 Summer Computer Simulation Conference.
Vries, T.J.A. de, 1994, Conceptual Design of Controlled ElectroMechanical Systems, Ph.D. thesis, University of Twente, Netherlands. Stein, J. and Louca, L., 1996, "A Template-Based Modeling Approach for System Design: Theory and Implementation", Transaction of The Society for Computer Simulation International, Vol. 13, No. 2, pp. 87-101. Breunese, A.P.J., Top, J.L., Broenink, J.F., and Akkermans, J.F., 1998, ”Libraries of Reusable Models: Theory and Application", Simulation, 71:7, pp. 7-22. Cellier, F.E., 1992, "Hierarchical Non-Linear Bond Graphs: A Unified Methodology for Modeling Complex Physical Systems", Simulation, 58:4, pp. 230-248. Hales, M. 1995, “A Design Environment for the Graphical Representation of Hierarchical Engineering Models”, Master of Science Thesis, Department of Mechanical Engineering, Michigan State University. van Dijk, J., 1994, On the role of bond graph causality in modeling mechatronic systems, Ph.D. thesis, University of Twente, Netherlands. Breunese, A.P.J., 1996, "Automated Support in Mechatronic Systems Modeling", Ph.D. Thesis, University of Twente, Netherlands. Cellier, F.E. and Elmqvist, H., 1993, "Automated Formula Manipulation Supports Object-Oriented Continuous System Modeling”, IEEE Control Systems, Vol. 13, No. 2, pp.28-38. Byam, Brooks, "Modular Modeling of Engineering Systems Using Fixed Input-Output Structure", Ph.D. Dissertation, Department of Mechanical Engineering, Michigan State University. OLMECO, 1991, OLMECO: Open Library for Models of mEchatronic COmponents, Part I-III, ESPRIT proposal EC 6521, Brussels, Belgium. Boeing, 1998, Easy5 User Guide, Boeing Computer Services, Seattle, WA.
