Mechatronics 98 J. Adolfsson and J. Karlsén (Editors) 1998 Elsevier Science Ltd. All rights reserved 873 Object-Oriented Modeling and Simulation of Mechatronic Systems with 20-sim 3.0 P.B.T. Weustink, T.J.A. de Vries, and P.C. Breedveld Drebbel Institute for Systems Engineering Department of Electrical Engineering, University of Twente P.O. Box 217, 7500 AE Enschede, The Netherlands Phone: +31-53 489 28 06, Fax: +31-53 489 22 23 E-mail: mechatronics@rt.el.utwente.nl, www-address: http://www.rt.el.utwente.nl/mechatronics Keywords: mechatronics, object-oriented modeling, conceptual design, modeling and simulation 1 INTRODUCTION There is an increasing need for controlled electromechanical systems with more flexibility, higher performance and reliability. It has been recognised that these systems are the result of design activities of not just one discipline, but of several disciplines [8]. This lead to the introduction of mechatronics, a design approach that combines mechanics with electronics and information technology to form both functional interaction and spatial integration in components, modules, products and systems. This approach differs from classical design patterns for controlled electro-mechanical systems, in which the design starts with the mechanical subsystems, next deals with the electrical subsystems and finally the controllers, that are designed to obtain the specified performance [1]. 1.1 Mechatronic design De Vries [2] described specific problems that occur during mechatronic design and stated that "a major cause of the problems is the lack of proper support for the conceptual design task". In the conceptual design stage a rough idea is developed of how the project will function and what it will look like. As the conceptual design stage is an early stage in the design process it is well suited to determine the functional interaction between the different subsystems. In general, the design of a mechatronic system will be a complex problem. Separating partial problems is a possibility to tackle such a complex design problem. In Simon's words [3]: "the design problem is ill-structured in the large, but well structured in the small. Hence the complex ill-structured design problem should be split into small well-structured problems to which a local problem solver can be applied. These well-structured problems should not just be considered in a specific domain, as this limits the solution space too strongly. Domain specific subproblems should be solved by taking into account the consequences of a solution in other domains or by finding alternative solutions in other domains, as seen in figure 1. consequences other domains local problem solver domain 1 ill-structured problem processing domain 2 domain 3 well-structured problem Figure 1: Schematic structure of solving illstructured problems
874 1.2 Object-oriented modeling Modeling, simulation and analysis tools are needed to support the mechatronic designer during these activities [2]. In the conceptual design stage these tools should consider the functional interaction between domain specific subsystems. There are many tools available that support modeling of dynamic systems, like 20-sim [5], Simulink [6], and Dymola [7], but the models all reside in the information domain (and the energy domain in 20- sim). This paper shows that mechatronic systems require an object-oriented modeling approach using the energetic domain information. The environments (i.e. 20-sim) should be changed in several ways to improve the support for this. 2 MECHATRONIC SYSTEM EXAMPLE As an example of the approach a simple laboratory setup called Linix is used, shown in figure 2. load flexible transm ission m otor Figure 2: Sketch of the Linix laboratory setup It consists of a computer-controlled actuator that drives a load using a flexible transmission. The power amplifier and the digital controller part of the setup are not shown here. The system is representative for a large class of mechatronic systems, since its dominant behaviour is that of a 4th-order system [1]. 2.1 Model of the system The top-level model is shown in figure 3. It is intrinsically based on power exchange between the connected submodels. For instance, the motor is a submodel with electrical power input and mechanical power output. This submodel can be decomposed into idealised elements as shown in another iconic diagram (figure 4). In this diagram the transducer is an elementary submodel described with simple gyrator equations: T = k V = k m m I ω 2.2 Object-oriented model characteristics (1) The model described above complies with a general model structure given in figure 5. Models of dynamic systems will generally have such a structure. The general model has the following characteristics: States, parameters, inputs and outputs are incorporated in submodels (encapsulation). The internal behaviour of a submodel is described as a composition of lower level submodels or a set of equations (part-of model hierarchy). A structure of interconnected sub-models can be specified without explicitly determining the computational causality (non-causal modeling). The instantiation of a submodel is separated from its definition in a library (abstraction). In the submodel definition, a separation can be made between externally accessible attributes (ports, parameters, states) and internal behaviour. c source J1 r 1 r 2 J 2 m otor m otor pulley flexible transm ission load pulley Figure 3: Iconic diagram of the system
875 R 1 L 1 k m electric port trans ducer J 3 R 2 rotation port Figure 4: Composite submodel of the motor Multiple versions for the internal behaviour may exist (polymorphism). Submodel definitions can be described as an extension of a more general submodel definition (kind-of hierarchy in the submodel library). In our view, these are the characteristics that an object-oriented model should have. When using an object-oriented approach, modeling now becomes the selection or creation of relevant submodels and the determination of their interconnections [2]. The structure of an object-oriented model is given in figure 5. 3 COMPUTER-BASED SUPPORT A modeling and simulation tool for mechatronic systems should be able to handle object-oriented models in multiple physical domains, since the model of a mechatronic system consists of the integration of submodels in multiple physical domains and the information domain. Tools should have a modeling technique that explicitly describes the energetic behaviour of the mechatronic system, and should have a proper support of the modeling process. Modeling itself is a dynamic process during which the kind of submodel often changes. In the Linix example the modeler could start with just a motor submodel and change it later into a brushless DC motor, for instance, when more is known about the design. It is the problem context that determines the implementation of the submodel. The same kind of submodel has several different implementations. In the example, the motor submodel is implemented as an iconic diagram of elementary submodels, whereas in another problem context a complex set of equations is required. Proper support would enable the exchange of submodel implementations with minimal effort. 4 LINIX EXAMPLE IN 20-SIM 3.0 Figure 5: Structure of an object-oriented model The 20-sim environment has been completely rewritten into a new version to implement the mentioned features. The bond-graph input of the Linix example is shown in the editor in figure 6. At the left-hand side, the complete part-of model hierarchy is shown (as described in figure 5). The implementation of the selected submodel in this hierarchy determines the kind of editor that is used
Figure 6 and 7: The 20-sim bond graph editor with the top-level model and the motor submodel 876
877 in the right hand part of the window. In figure 6 the top-level model Linix is selected. The implementation is a bond graph of the process, together with a block diagram that represents a controller of the angular position of the load. Both the DC motor and the amplifier submodels have an implementation, the other submodels only have a type description in order to demonstrate that the tool supports a topdown approach. The motor submodel is implemented as a bond graph containing the parts shown in figure 4 as ideal bond graph elements. Figure 7 shows this implementation. Next the motor submodel changed with a view mouse clicks from a bond graph implementation to a set of equations. The equation editor is now used to represent the implementation of the selected submodel (figure 8). The upper part of the equation editor shows the type information, in this case the two ports and the type parameter km. The lower part is for entering and modifying the equations in the SIDOPS+ language [4]. The equation editor gives the user feedback through extensive equation analysis and feedforward through colour syntax highlighting. When the amplifier submodel is selected in the hierarchy, the editor subwindow changes into an iconic diagram. The implementation of the amplifier is shown in figure 9. The amplifier has an input signal m and an electric port p, represented by two nodes, p high and p low. Ports and signals are represented in the diagram by generic plugs. When the model is implemented completely, it is translated into a set of simulation instructions that is performed by the simulator. Since it is one environment, there is shared memory between the simulation kernel, plot package and the model editors. This enhances model consistency, and enables submodel debugging and editor updates during simulation. Figure 8: The 20-sim equation editor
878 5 CONCLUSIONS The new version of 20-sim features object-oriented models, thus including: multi physical domain and the control domain polymorphic models multiple model representations possible transformations between these libraries with submodels organized in a kind-of hierarchy (with inheritance of relevant properties) These features make 20-sim 3.0 suited for mechatronic system design. Future work resides on the development of more domain specific libraries with iconic diagram representations. REFERENCES [1] Coelingh, H.J., T.J.A. de Vries and J. van Amerongen (1998), Automated Performance Assessment of Mechatronic Motion Systems During the Conceptual Design Stage, to be presented at ICAM 1998, Okayama, Japan. [2] Vries, T.J.A. de (1994), Conceptual design of controlled electro-mechanical systems, Ph.D. thesis, University of Twente, Netherlands [3] Simon, H.A. (1973), The structure of illstructured problems, Artificial Intelligence 4, 181-20. [4] Breunese, A.P.J. (1997), Automated Support in Mechatronic Systems Modeling, Ph.D. thesis, University of Twente, Enschede, Netherlands. [5] Controllab Products (1997), 20-sim Reference Manual, Enschede, The Netherlands, http://www.rt.el.utwente.nl/20sim [6] The Mathworks Inc. (1998), Simulink 2.2, http://www.mathworks.com/products/simulink [7] Dynasim AB (1998), Dymola - Dynamic Modeling Laboratory, http://www.dynasim.se [8] Buur, J. (1990), A theoretical approach to mechatronic design, PhD thesis, Institute for Engineering Design, Technical University of Denmark, Lyngby, Denmark. Figure 9: The iconic diagram editor showing the amplifier implementation