Simulation Practice and Theory 7 (1999) 481±492
www.elsevier.nl/locate/simpra
20-S I M software for hierarchical bond-graph/ block-diagram models Jan F. Broenink * Control Laboratory, Faculty of Electrical Engineering, University of Twente, P.O. Box 217, NL-7500 AE Enschede, Netherlands Received 19 January 1999; received in revised form 1 June 1999
Abstract We discuss the modeling and simulation package 20-S I M , a tool for modeling and simulation of dynamic behavior of engineering systems. Engineering systems as application domain means that we focus on systems that span multiple physical domains and the information domain. The 20-S I M software is an interactive tool, where model entry and model processing are fully integrated. This means that already during model entry and editing, models can be checked on their consistency. 20-S I M has its own simulator, using sophisticated numerical integration methods, taken from. internationally accepted numerical libraries. The use of 20-S I M is demonstrated by an example, in which a 3-D O F S C A R A robot with controller is modeled and simulated. Ó 1999 Elsevier Science B.V. All rights reserved. Keywords: Software; Object oriented; Bond graphs
1. Introduction We discuss the modeling and simulation package 20-S I M [7,11], a tool for modeling and simulation of dynamic behavior of engineering systems. 20-S I M is the mature version of C A M A S [6,10], however this name could unfortunately not be used for trademark reasons. The purpose of 20-S I M is to support the engineer in the process of design, analysis and diagnosis of engineering systems using modeling and simulation. Engineering systems as application domain means that we focus on systems that span multiple physical domains and the information domain. In our opinion,
*
Tel.: +31-53-489-2793; fax: +31-53-489-2223; web: http://www.rt.el.utwente.nl/bnk E-mail address:
[email protected] (J.F. Broenink)
0928-4869/99/$ - see front matter Ó 1999 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 8 - 4 8 6 9 ( 9 9 ) 0 0 0 1 8 - X
482
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
the tool should complement the talents of the user such that he can do modeling and simulation eciently. 20-S I M models are hierarchical structured bond-graph and block-diagram models. Furthermore, non-causal equations can be used to enter own submodels or equation models. The modeling approach used here is close to object-oriented physical-systems modeling, which is currently often used [1,2,16,24]. This can be seen as follows: 20-S I M models are declarative, hierarchically structured, and encapsulation is fully supported. Furthermore, due to allowing hierarchy, the notion of de®nition and use of models are distinguished (i.e. the class concept and instantiation). Note that the bond-graph approach itself is actually a kind of objectoriented approach to physical systems modeling. Since bond graphs came into existence before the term object oriented was used in the ®eld of physical systems modeling, bond graphs can be seen as an object-oriented physical-systems modeling paradigm avant-la-lettre. In Section 2, we give an overview of 20-S I M , focussing on the modeling part. Via a benchmark problem, dierent aspects of 20-S I M are illustrated (Section 3). In Section 4 we also give an outlook in broad outlines on further developments.
2. Overview of 20-S I M The 20-S I M software is organized as an interactive tool, where model entry and model processing are fully integrated. This means that already during the model entry process, veri®cation of models can be performed and results are shown in the model itself. In this way, we are able to give feedback as early as possible in the modeling process, which enhances the quality of the tool. In Fig. 1, an overview of the software is given. In the rest of this section, we will discuss the dierent parts of 20-S I M . 2.1. Modeling part The graph editor is the central part here. It is a drawing editor to draw graphical models consisting of bond-graph parts and/or block-diagram parts. Also, the results of the causal analysis are shown here in the bond graph. The equation editor will be invoked when an equation model is opened. Furthermore, the simulator can be started from here, and model compilation will be called ®rst, if necessary (when the hierarchical model is newer than the simulation model). 2.1.1. Models 20-S I M models are hierarchical structured block-diagram and bond-graph models. The model on the top of the hierarchy is called a main model. The models on the lowest level in the hierarchy are called elementary models, and are sets of equations or assignment statements. An example of a hierarchical structured model is presented in Section 3. Furthermore, it is possible to specify main models as a set of equations,
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
483
Fig. 1. Overview of 20-S I M .
although then no submodels can be used. Hence, 20-S I M is a multiformalism package, supporting equations, block diagrams and bond graphs as model description forms. Note that the use of hierarchy and submodels can be worked out really elegantly, since bond graphs are non-causal and port-based. This means that the equations behind the bond-graph elements and submodels are speci®ed as equalities (that means variables need not be tagged as inputs or outputs yet) and the bond-graph interfaces are ports, each with two variables being computed in opposite directions. As a result, the submodel contents are encapsulated: the contents need not exactly be known, when using submodels in a graphical model, since the connection does not in¯uence the contents anymore. This is however the case when physical-system submodels are speci®ed as input±output models. Note that when in a submodel only information processing is done (like digital controllers) and it is speci®ed as an input±output description, there is no problem using encapsulation, since there is no choice for input or output at the interface elements. Models containing only information processing parts, like digital controllers or command sequences, can now be speci®ed as input±output models with assignment statements. This implies that during simulation the statements are executed in the speci®ed form and order (i.e. no rewriting or sorting of the statements is done during model processing). Furthermore, variables may be assigned more than once a value.
484
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
To distinguish statements from equations, the assignment symbol `: ' is used instead of the equation symbol ` '. Note that within one equation submodel assignments and equations may not be mixed. This is, however, not really a constraint, since in such a situation, the model can be split up into two parts: one containing the assignments (purely information processing) and the other part of the equations (physical system description). 2.1.2. Model storage Models and submodels are stored in a kind of library implemented as a list of directories of models. This list can easily be extended to store, for example, all models for one project in one directory. Currently, 20-S I M supports reusability of submodels via true encapsulation due to the use of the bond-graph paradigm. Note that submodel reuse is now on a practical level, which can lead to a substantial increase in eciency of the modeling process. Although it is not yet a complete database facility, (sub)models can be reused in other modeling projects and shared with other modelers. However, a complete library facility has been prototyped [5]. 2.1.3. Model compilation Generation of a simulation model, i.e. a set of assignment statements suitable for computation, is performed by the model processing module, which after reading all submodels (expansion) derives the causal form of the equations using the MSCAP algorithm [12]. This causality assignment algorithm is an enhanced version of the traditional Sequential Causality Assignment Procedure [21], in order to also assign causality properly when bond loops are present. Using the results of the causality assignment, the equations are symbolically rewritten to assignment statements and sorted. After that, the resulting simulation model is written to ®le in some format (code generation). We use a proprietary, macro-code like, 3-address instruction format. Sorting of statements is common in most continuous system simulation packages (T U T S I M , A C S L , etc). Rewriting equations is necessary in those packages that allow equations, i.e. non-causal models, as model input. Besides 20-S I M and other bondgraph software, p.e. Enport [27], M S 1 [22], and C A M P [18], packages like Dymola [15], Modelica [24,26], gP R O M S [3] and ULM [20] need this feature. Causal analysis is speci®c for bond-graph packages, and expansion is necessary when submodels are allowed. Furthermore, the 20-S I M compiler produces ecient simulator code by dividing assignment statements into dierent groups (static, input, dynamic, and output). The strategy is to have the dynamic section as small as possible (in A C S L this is the D E R I V A T I V E section), because it is computed every time when a model computation is required in the numerical integration process. Especially, when the integration method uses more than one model computation for determining the next value of the states, as with implicit methods, the gain in simulation speed can be serious. The distribution of assignment statements among the four groups is automated in the model-processing phase to avoid erroneous models or not ecient simulatable models [8]. Note that a sophisticated package like ACSL [25] does not oer such a
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
485
complete automated distribution process: p.e. one has to place static equations by hand in the I N I T I A L section. Static equations are those of which all variables do not depend on time (e.g. relations between parameters), and can therefore be computed once per simulation run at the beginning (compare p.e. to the I N I T I A L segment of A C S L ). Input equations are those time-dependent equations, that are necessary for calculating the rates, and may not be part of the dynamic section (for example generating random numbers). Output equations, are all non-static equations that do not contribute to the calculation of the state vector. That is, these equations are not needed for calculation of the rates, but must be calculated at the end of each simulation step. This code-generating strategy resulted in a performance increase of about 3±5 times using a reasonable sized rigid body robot model (2500 small equations, 24 states) compared to let all equations be calculated every model call [8]. 2.1.4. Connection to other packages The editors have an export facility to ModelicaTM code. However, this output ®lter is only available in an experimental version [9]. After an export has been made, the Modelica compiler itself does the assembling of the hierarchical model structure into one ¯at model, and generates equations in Dymola format. Furthermore, 20-S I M has the facility to generate code as a module in the programming language C, and simulation results can be exported in Matlab format (see Fig. 1). 2.1.5. Beyond bond graphs Currently, functionality was added which allowed 20-S I M to better support control systems and controlled physical systems. Basic facilities for discrete and combined systems (i.e. models consisting of continuous-time and discrete-time parts) have been added. For instance, computer controlled systems can now be modeled and simulated more naturally than with only facilities for continuous-time models. A/D and D/A submodels are available which implement the Analogue to Digital conversion, respectively, the Digital to Analogue conversion including quantization and clipping the output signal as is common for practical converters. In order to let parameters denoting the sample time in all submodels have the same value, they must be declared as of type sample time. Also editing one sample time parameter in the simulator of 20-S I M , results in changing all sample time parameters in all submodels, thus ensuring that all those parameters have the same value. We have prototyped a proper solution [8], which is now being implemented in the coming version of 20-S I M . 2.1.6. Modeling language S I D O P S As model description formalism, the language S I D O P S has been developed [6,10]. S I D O P S is a functional language in which besides the constitutive relations also the graphical models and submodels are described. All information about model elements is speci®ed in this model description language, isolating completely the modeling information from the 20-S I M software. This means that 20-S I M is open with
486
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
respect to models. Consequently, the basic models can be changed by the user, giving as much freedom as possible. Note that some provisions are taken in order not to change basic models undeliberately: they are stored in a separate directory, which can be made read-only. The user automatically saves to his own model directory. Bond graphs and block diagrams are treated as labeled and directed graphs. Since a graph is a set of vertices connected by edges, a list of vertices and a list of edges is basically enough to describe bond graphs and block diagrams. Of course identi®cation and the interface need to be speci®ed, i.e. name and size of power ports, signal inputs and signal outputs. In the graph these interface elements are treated as vertices. Note that the annotations to the graph (i.e. `labels' and `directions') contain more information than usual in graph theory: A power bond can have two `directions': the causality (computational direction) and the orientations (power direction). Furthermore it must be speci®ed to which port of a submodel (i.e. interface element of a vertex itself) a bond is connected. Elementary models are described as a set of equations, preceded by declarations of the used identi®ers. The following types of identi®ers exist: constants (to denote p.e. physical constants), parameters (remaining constant during a simulation run), local variables. Also the interface must be speci®ed, i.e. name and size of power ports, signal inputs and signal outputs. The two conjugate variables, eort and ¯ow, represented by one port name are denoted as .e and .f, respectively. The relation between the interface elements and the identi®ers in the equations is established via the names of the ports, inputs and outputs. See Listing 1 in Section 3 for an example of S I D O P S text. The part of S I D O P S describing graphs is computer generated since graphs are entered graphically using the bond graph editor and the result of causal analysis can be shown in the graph. Thus users are in principle not confronted with this part of S I D O P S . 2.2. Simulation The speci®cations for simulation are stored separately from the model to allow dierent simulation experiments with one model that is guaranteed the same. The simulator is interactive: results are shown instantly during the simulation run. Numerical values can be stored on ®le (proprietary format or M atlab format). Besides the basic numerical methods like Euler and Runge±Kutta, the variable step Runge± Kutta±Fehlberg method (fourth order) and a D A E solver based on the B D F formula [17] using D A S S L R T from the Netlib numerical library [13] are included. Other facilities are: · Parameter optimization using the standard optimization methods used in control engineering are covered (e.g. Newton Raphson, continous descent, steepest descent, perpendicular search). · Multiple run featuring linear and logarithmic sweeps of all static values, i.e. both parameters and initial conditions. · Data input from ®le whereby the data are interpolated when the data time points do not match the simulation time points. This feature can be used for: Constitutive relations of elements speci®ed as data curves instead of formulas.
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
487
Importing measurement data, to compare with simulation results, thus performing validation of the simulation. We did some performance tests with dierent class-room type models, comparing 20-S I M , A C S L , Dymola and S I M U L I N K [23]. It turned out that 20-S I M is about 3±5 times faster than ACSL or Dymola, which already outperform S I M U L I N K [19]. See also the performance comparison in the next section. 3. Example The facilities of both the modeling description formalism (bond graphs) and the facilities of 20-S I M are illustrated by an example in which a computer controlled electromechanical system is modeled and simulated. Aspects like reusability, extendibility and sharability of model parts are investigated. Furthermore, tests on simulation speed and accuracy of the numerical results will be discussed. Results are compared qualitatively to other, commonly used packages like S I M U L I N K . 3.1.
SCARA
robot
We used a 3-D O F rigid body robot of S C A R A type as a test model. This robot model is Comparison 11 of the benchmark series of Eurosim [14]. The robot has two vertical revolute joints and one vertical translational joint. The axes of all three joints are vertical (parallel to the z-axis). It is driven by three servomotors, for which basic models are used. To control a point-to-point motion, a rather primitive singleaxis PD control is used, whereby the steering voltages are limited to resemble the real situation. A sketch of the robot is given in Fig. 2 The main model as drawn in the 20-S I M graph editor is shown in Fig. 3:
Fig. 2. Sketch of the 3-D O F rigid body robot of
SCARA.
488
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
Fig. 3. Screen dump of the 20-S I M graph editor with the main model of the 3-D O F The robot submodel itself is highlighted.
SCARA
robot loaded.
The robot model (scara 1) consists of the classical equations of motion, speci®ed as an equation submodel with three power ports (the load axes of the motors) and three signal outputs (the joint vector: two joint angles q1 , q2 and one joint distance q3 ). Part of the listing of this equation submodel is shown below. Listing 1: Partial SIDOPS text of the robot model scara1 class scara version 1 # General_Description: # SNE comparison 11 SCARA robot interface ports: a1, a2, a3 # actuators giving the steering Torques outputs: real q1, q2, q3 # coordinates of robot: angle, angle, distance parameters real m1, m2, m3A, m3L, l3m # masses real L1, L2, u3, g # lengths and gravity accel
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
variables real dq1, dq2, dq3 real ddq1, ddq2, ddq3 real T1, T2, T3
489
# ®rst derivatives of robot coordinates (i.e. velocities) # second derivatives of robot coordinates # torques, applied by the motors on the robot # Mass matrix terms # Determinant for mass matrix inverse # b-vars # moments of inertia # cos(q2) and sin(q2)
real m11, m12, m21, m22, m33 real det12 real b1, b2, b3 real l1, l2, l3, m3 real cosq2, sinq2 equations # integrations dq1 int (ddq1) . . . etc # ddqi b / M, the equations of motion ddq1 (m22 b1 - m12 b2) / det12 ddq2 (m11 b2 - m21 b1) / det12 ddq3 b3 / m33 det12 m11 m22 - m12 m21 # M matrix m11 l1 + 2 I2 cosq2 + l3 b1 T1 + l2 (2 dq1 dq2 + dq2 dq2) sinq2 . . . etc # Moments of Inertia l1 (m1 / 3 + m2 + m3) L1 L1 . . . etc
The three motors and velocity feedback (tacho) are modeled as the basic electromagnetic transduction with only the electrical time constant taken into account (see Fig. 4). The motor model is set up hierarchically: the motor models as shown in Fig. 3 (mtrtach1) consist of a motor submodel and a tacho. The motor submodel (motor1) consists of the transduction and electrical resistance and inductance. For the PD-controllers and the setpoint generators (step function), submodels standard available in 20-S I M were used. So, only the main model, the S C A R A - robot model and the motor models are speci®cally made for this test problem. This simulation, using the implicit integration method BDF, used 0.04 s on a Pentium II 400 MHz, running Win NT 4. 1889 model computations were needed. A screen dump of the simulator showing the responses of the joint vector on a step input at t 0:2 from
0; 0; 0 to
2; 2; 0:3 is given in Fig. 5. The same model and experiment need 2.23 s on a comparable PC (P-II 400), when Matlab/S I M U L I N K is used [28].
490
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
Fig. 4. The motor model, showing an example of hierarchy: mtrtach1, above, and motor1 below.
Fig. 5. Screen dump of the 20-S I M simulator with the result of the step response shown (the joint vector: two joint angles q1 , q2 and one joint distance q3 ).
4. Conclusion Supporting bond graphs, block diagrams and equations as model description formalisms gives a convenient way of modeling physical systems either computer controlled or not. In the robot example of Section 3, we could easily use the standard
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
491
equations of motion as is common in rigid body dynamics. Since these equations were given, and only for the parameters involved values were available, the 20S I M model was set up rather quickly. Other experiences in teaching, research and industrial engineering support this statement. Reuse and extension of existing submodels was used in building 20-S I M models, including the example model of Section 3. Not only due to the graphical model entry and editing features of the software, but mainly due to the energy and port-based character of the physical system submodels, reuse and extension can be done elegantly and straightforwardly. It is the bond-graph approach that is essential here. Especially when the bond-graph way is compared to input±output-based physical system submodels as is necessary when using a pure block diagram package like S I M U L I N K . Future developments of 20-S I M include the coverage of more physical properties (like units and quantities) by implementing S I D O P S + [4], and supporting hierarchy and encapsulation in the way as is done in object-oriented software design by explicitly separating the interface part from the rest of the submodel. Then, it becomes straightforward to build and maintain dierent implementations of the ÔsameÕ submodel (like a simple linear resistor versus a nonlinear one, describing e.g. friction and stiction).
Acknowledgements We thank Paul Weustink and Frank Groen for their work on the design and implementation of the 20-S I M software, and other colleagues of the Control Laboratory for valuable comments during the development of the tool.
References [1] M. Andersson, Object-oriented modeling and simulation of hybrid systems, PhD Thesis, Lund Institute of Technology, Sweden, 1994. om, H. Elmqvist, S.E. Mattson, Evolution of continuous-time modeling and simulation, in: [2] K.J. Astr Proceedings of the 12th European Simulation Multiconference (ESMÕ98), SCS Publishing, Manchester, UK, 1998, pp. 9±18. [3] P.I. Barton, C.C. Pantelides, Modeling of combined discrete/continuous processes, AIChE J 40 (1994) 966±979. [4] A.P.J. Breunese, J.F. Broenink, Modeling mechatronic systems using the SIDOPS+ language, Simulation Series 29 (1) (1997) 301±306. [5] A.P.J. Breunese, J.L. Top, J.F. Broenink, J.M. Akkermans, Libraries of reusable models: theory and application, Simulation 71 (1) (1998) 7±22. [6] J.F. Broenink, Computer-aided physical-systems modeling and simulation: a bond-graph approach, PhD Thesis, Faculty of Electrical Engineering, University of Twente, Enschede, Netherlands, 1990. [7] J.F. Broenink, Modelling simulation and analysis with 20-Sim, Journal A Special Issue CACSD 38 (3) (1997) 22±25. [8] J.F. Broenink, P.B.T. Weustink, A combined-system simulator for mechatronic systems, in: European Simulation Multiconference, Budapest, Hungary, 2±6 June 1996.
492
J.F. Broenink / Simulation Practice and Theory 7 (1999) 481±492
[9] J.F. Broenink, Object-oriented modeling with bond graphs and Modelica, in: J.J. Granda, F.E. Cellier (Eds.), Proceedings of (ICBGM'99) Fourth International Conference on Bond Graph Modeling and Simulation, Simulation Series, vol. 31, No. 1, SCS Publishing, ISBN: 1-56555-155-9, 1999, pp. 163± 168. [10] J.F. Broenink, J.W. Bekkink, P.C. Breedveld, Multibond-graph version of the CAMAS modeling and simulation environment, in: P.C. Breedveld, G. Dauphin-Tanguy (Eds.), Bond Graphs for Engineers, Elsevier, Amsterdam, 1992. [11] Controllab Products Inc, 20-S I M Version 2.3, User manual, Enschede, Netherlands, 1998 (http:// www.rt.el.utwente.nl/20sim). [12] J. van Dijk, On the role of bond graph causality in modeling mechatronic systems, PhD Thesis, Faculty of Electrical Engineering, University of Twente, Enschede, Netherlands, 1994. [13] J. Dongara, E. Grosse, Netlib library repository, AT&T Bell Laboratories, Computing Research Homepage, Murray Hill, NJ, 1995 (http://www.netlib.org/). [14] H. Ecker, Comparison 11: scara robot ± de®nition; solution in ACSL, Eurosim ± Simulation News Europe, No 22, March 1998, pp. 30±33. [15] H. Elmqvist, A structured model language for large continuous systems, PhD thesis, Dept Automatic Control, Lund Institute of Technology, Sweden, 1978. [16] H. Elmqvist, F.E. Cellier, M. Otter, Object-oriented modeling of hybrid systems, in: Proceedings of European Simulation Symposium, Delft, Netherlands, 1993, pp. 31±41. [17] C.W. Gear, L. Petzold, ODE methods for solution of dierential/algebraic systems, SIAM Journal of Numerical Analysis 21 (4) (1984) 716±728. [18] J.J. Granda, Computer generation of physical system dierential equations using bond graphs, Journal of the Franklin Institute 319 (7/2) (1985) 243±256. [19] N.A. Groot de, Modeling state events in 20-sim, MSc Thesis, Faculty of Electrical Engineering, University of Twente, Enschede, Netherlands, 1998. [20] A. Jeandel, F. Boudaud, P. Ravier, A. Bushing, ULM: un language de modelisation, a modeling language, in: Proceedings of the CESAÕ96 IMACS Multiconference, IMACS, Lille, France, 1996. [21] D.C. Karnopp, R.C. Rosenberg, Analysis and simulation of multiport systems: the bond graph approach to physical system dynamics, MIT Press, Cambridge, MA, 1968. [22] F. Lorenz, Modelling System 1, User manual, Lorenz Simulation, Liege, Belgium, 1997. [23] Mathworks Inc, Simulink, a program for simulating dynamic systems, The Mathworks Inc, Natick, MA, 1992. [24] S.E. Mattsson, H.E. Elmqvist, J.F. Broenink, Modelicaä ± an international eort to design the next generation modeling language Journal A Special Issue CACSD. 38 (3) (1997) 16±19. [25] E.E.L. Mitchell, J.S. Gauthier, Advanced continuous simulation language (ACSL), Simulation 26 (5) (1976) 72±78. [26] Modelica, Modelicaä ± a uni®ed object oriented language for physical systems modeling, 1997 (http:// www.modelica.org). [27] R.C. Rosenberg, A UserÕs Guide to ENPORT-4, Wiley, New York, 1974. [28] J. Scheikl, Comparison 11: Matlab/Simulink numerical inversion/hybrid approach, Eurosim ± Simulation News Europe, No. 25, March 1999, pp. 50.