modeling mechatronic systems using the sidops+ language - CiteSeerX

Published in: Proceedings of ICBGM'97, 3rd International Conference on Bond Graph Modeling and Simulation, Phoenix, Arizona, January 12-15, 1997, SCS Publishing, San Diego, California, Simulation Series, Vol.29, No.1, ISBN 1-56555-050-1.

MODELING MECHATRONIC SYSTEMS USING THE SIDOPS+ LANGUAGE A.P.J. Breunese and J.F. Broenink Control Laboratory, Department of Electrical Engineering University of Twente Enschede, Netherlands e-mail: [email protected]

ABSTRACT Automated modeling is a field of research that is subject to considerable evolution. Both the increase in available computer power and better insight in the modeling and design process lead to a stream of new opportunities for automated modeling support. To make this support possible, a language is needed that forms the medium for the exchange of information between the computer and the user. In this paper, we propose the SIDOPS+ model description language that not only covers state of the art automated modeling techniques, but that also provides openness towards future developments. Keywords: model description languages, model reusability, bond graphs, mechatronics

1 INTRODUCTION Modeling and simulation are frequently used in the design and analysis of engineering systems. The computer plays an important role in these activities, since it can provide the numerical results for a given simulation model, and because it can assist the engineer in composing models out of existing model fragments. In the interaction between the user and the computer, a formal description is needed that is strict enough to provide unambiguous information to the computer, and that is also powerful enough to deal with the equations and graphs that are used in modeling. A wide range of model description languages already exists. Still, we propose a new language because we feel that the level of automated modeling support possible with existing languages is insufficient. Because of advances in various areas of computer science (e.g. Artificial Intelligence, Object Oriented databases, graphical user interfaces, etc.), and because of better insight in the modeling process, new techniques and types of models become feasible. This new language will include many of the features found in present-day modeling and simulation languages, such as Dymola (Cellier and Elmqvist 1993), SIDOPS (Broenink 1986; Broenink et al. 1992), ACSL (Mitchell and Gauthier 1993), Matlab (Mathworks 1992), and others. Because of the focus on multidisciplinary (mechatronic) systems, we prefer to start from a language that is domain-independent. The bond graph-based language SIDOPS is used for that purpose. It has

the additional advantage of being implemented in the 20-SIM software that already reflects our view of automated modeling support. The name of the new language (“SIDOPS+”) clearly indicates its heritage. SIDOPS+ can be viewed as the third generation of the SIDOPS language. The first version of SIDOPS only supported single-dimensional bond-graph and block diagram models (Broenink 1986). This version was used in the CAMAS modeling and simulation software (Broenink 1990). The second generation (Broenink et al. 1992) is used in today’s commercially available 20-SIM (the new name of CAMAS) (Controllab Products 1996) and provides support for multidimensional models. The addition of the “+” in the name of the language not only indicates the addition of new features, but also acts as a token for openness towards new applications and tools. Compared to SIDOPS, the new language provides increased possibilities for automated modeling support. Moreover, the range of systems that can be described in the language is extended. The main part of this paper is formed by section 2. In this section, we deal with the most important new features provided by SIDOPS+. The new features will be illustrated by means of examples. In section 3, we will briefly discuss the state of the art of the implementation of the language in the software products (modeling, model processing, simulation) we are working on. Section 4 presents conclusions.

2 NEW FEATURES In this section, we will describe the features in SIDOPS+ that have been added when compared to its predecessor SIDOPS. In sections 2.1 and 2.2 we discuss the new model structure that enables a much broader variety in modeling approaches and model representations. This is the most radical change in the language. However, this addition does not impede the use of the previous model structure. Both in this aspect, and other aspects, we have considered the value of legacy models and tried to ensure minimal migration cost. In section 2.3 we discuss the possibility now offered by SIDOPS+ to describe combined systems (Cellier 1979), i.e. systems involving both continuous-time and discrete-time parts. The final part of this section highlights the issues of model reusability (section 2.4) and openness (section 2.5). These issues affect the design of the language in many places. In fact, these

301

Published in: Proceedings of ICBGM'97, 3rd International Conference on Bond Graph Modeling and Simulation, Phoenix, Arizona, January 12-15, 1997, SCS Publishing, San Diego, California, Simulation Series, Vol.29, No.1, ISBN 1-56555-050-1.

issues are basic guidelines that have played their role throughout the development of SIDOPS+.

2.1 Polymorphic Modeling In many cases, a complex system model is set up as a hierarchy of subsystem models. This feature is supported in many model description languages. However, frequently the support is limited to well-defined and self-contained subsystem models. That is, a subsystem model has to be completely defined before it can be used in a larger system model. As a consequence, the modeling process is a bottom-up process. This is not the only way practical users want to work though. In practical approaches such as top-down or meet-in-themiddle modeling approaches, a users wants to specify that some function is relevant, but exactly how that function is realized is not immediately relevant. Therefore, the need to separate the interface and the internals of a subsystem model arises. This is accomplished in SIDOPS+ by following the polymorphic modeling approach (De Vries et al. 1993; De Vries 1994). Each model consists of a type (the interface) and a specification (the internal parts that define the behavior). There may be different specifications for one type. If these specifications are stored in a library, it is a matter of clicking the right entry in a list of specifications to make modeling decisions. Although polymorphic modeling (or similar concepts) have been available for some time, there are few tools that deal with such models. Therefore, SIDOPS+ also supports the traditional ‘monomorphic’ model style that combines the interface and the internal parts into a single description. To illustrate the difference between monomorphic models and polymorphic models, consider listings 1, 2 and 3. In listing 1 we see two models of frequently used controller types, the proportional (P) and proportional-integral (PI) controllers. Large parts of the model descriptions are the same. The common parts, i.e. the input and output as well as the gain parameter that is typically present in a controller, are formulated as the type in listing 2. In listing 3, the model descriptions (the specifications) refer to the type and only the extra information (that is specific to the controller type) is specified in each of the two model descriptions. equation model P; inputs real err: outputs real outp; parameters real Kp; equations outp = Kp*err; end;

equation model PI; inputs real err: outputs real outp; parameters real Kp, Ki; equations outp = Kp*err + Ki*int(err); end;

Listing 1: Monomorphic controller models

equation type ctrl; inputs real err; outputs real outp; parameters real Kp; end;

Listing 2: The (polymorphic) controller type equation specification P; type ctrl; equations outp = Kp*err; end;

equation specification PI; type ctrl; parameters real Ki; equations outp = Kp*err + Ki*int(err); end;

Listing 3: Possible specifications for the controller type Unlike monomorphic models, polymorphic models are not fully determined after selecting submodels. Each submodel consists of a number of types that need to be linked to a specification before the model is fully specified. This is done in the socalled realization. The realization is a description of the modeling decisions that lead to the hierarchical model structure. A simple example is shown in listing 4. This realization describes the top level model of figure 1. The process submodel is decomposed as shown in figure 2. Although not shown in the example, it is also possible to use a sub-realization to describe the joint effect of a number of modeling decisions. realization example; model crtl_sys; structure path : cycloidal; controller : PI; process : decomp structure amplifier : opamp; actuator : solenoid; plant : mass; sensor : encoder; end; end;

Listing 4: Realization

Figure 1: Controlled system model

Figure 2: Process submodel decomposition

302

Published in: Proceedings of ICBGM'97, 3rd International Conference on Bond Graph Modeling and Simulation, Phoenix, Arizona, January 12-15, 1997, SCS Publishing, San Diego, California, Simulation Series, Vol.29, No.1, ISBN 1-56555-050-1.

2.2 Multiple Representations In mechatronic systems modeling, different levels of abstraction play a role. Furthermore, within a single level of abstraction, different aspects may be relevant. Therefore, the SIDOPS+ language supports model descriptions at three abstraction levels (Top and Akkermans 1994), and different representations within abstraction levels. The three abstraction levels are: – The technical component level. At this level, models are described as a network of devices that can be recognized in the actual system as it is realized. This level is represented by component graphs. – The physical concept level. Here, the physical processes that take place in actual devices are modeled. The conceptual network structure is captured in one of three representations: bond graphs, block diagrams, or ideal physical models (IPMs). – The mathematical level. This level captures the quantitative description of the phenomena associated with the physical processes. The description can be a set of (acausal) equations, or a portion of computer code that calculates the output variables from the input variables. The three-layer model structure is illustrated in figure 3. For each of the layers in the model, the polymorphic modeling approach that was described in the previous section can be used.

profit from the use of different representations, without suffering from inconsistencies that could arise if these safeguards were not built in (De Vries 1994).

2.3 Combined Systems A large number of physical systems are controlled using digital computers. Especially in mechatronics, it is important to consider the effect of the digital controller on closed loop performance, since mechatronic design is based on a trade-off between physical system design and controller design. Therefore, SIDOPS+ should be able to describe a combined system (Cellier 1979), i.e. a system consisting of a continuous-time part and a discrete-time part. The discrete-time nature of digital computers leads to the introduction of discrete variables in SIDOPS+. These variables are defined at multiples of a sample time only. To link these variables to continuous-time variables, SIDOPS+ defines the sample and hold primitives. The sample primitive is also used to determine the sample interval for a group of discrete-time variables that are linked through equations or connections. A SIDOPS+ compiler should verify that there is no direct coupling between discrete-time and continuous-time variables. Listing 5 shows a description of a simple AD/DA board that takes care of a single-channel data conversion between a physical system and a control computer. equation model io_board; inputs real from_system; discrete real from_computer outputs real to_system; discrete real to_computer; parameters real h; equations to_computer = sample(from_system, h); to_system = hold(from_computer); end;

Listing 5: Discrete-time and continuous-time

Figure 3: Three-layer model structure Different representations may be used in combination. For instance, it is possible to use a bond graph specification for one component and an IPM specification for another. Because all representations are port-based networks, it is possible to map one representation on the other. This knowledge is embedded in the SIDOPS+ language. As a consequence, it is possible to

Whereas physical systems are described by a set of simultaneous equations that may need to be rewritten and sorted before computer simulation is possible, the portions of the model that are implemented on a digital computer are frequently specified as a sequential algorithm, which usually includes statements that affect the flow-of-control. Sequential algorithms should not be rewritten or sorted. Therefore, SIDOPS+ supports two model representations at the mathematical level: acausal equations can be used to describe model parts with a physical background, sequential statements are a more suitable representation for model parts with a computational background. Listing 6 demonstrates the use of computer code in SIDOPS+. This model has two vectors X and Y as its inputs and determines the sample covariance of these vectors. The

303

Published in: Proceedings of ICBGM'97, 3rd International Conference on Bond Graph Modeling and Simulation, Phoenix, Arizona, January 12-15, 1997, SCS Publishing, San Diego, California, Simulation Series, Vol.29, No.1, ISBN 1-56555-050-1.

model also demonstrates the use of arguments. The argument N is used to specify the size of the vectors. The use of arguments enables the construction of generic submodels. program model sigma_xy; arguments N; inputs real X[N], Y[N]: outputs real cov; variables real mu_X, mu_Y, tmp; integer i; statements mu_X := sum(X)/N; mu_Y := sum(Y)/N; tmp := 0; for i := 1 to N do tmp := tmp + (X[i] – mu_X)*(Y[i] – mu_Y): end; cov := tmp/(N-1); end;

Listing 6: Computer code in SIDOPS+ Besides the possibility to define procedural code as a model, it is also possible to define custom functions in the same manner. A custom function may have one or more arguments, and returns a single value. Custom functions can be used in acausal and causal models. The level of support provided for combined systems in SIDOPS+ is compatible with the facilities found in modern simulation packages. A combined-system simulator for the 20SIM environment has already been developed (Broenink and Weustink 1996), so that the new SIDOPS+ features can be used as soon as the language is adopted in this environment.

2.4 Reusability Making models of complex, non-trivial systems and processes is a time-consuming and sometimes expensive affair. Therefore, it is highly advisable to retain the knowledge that is captured in models for future reference. The idea of model libraries has been proposed to make modeling knowledge available for reuse, for instance in the OLMECO project (Top et al. 1995) that spawned the redesign of the SIDOPS language. An important characteristic of model reuse is that models may be used by others than the original author. Therefore, it is quite likely that the user of a model has not gone through the process of confidence building that is traditionally coupled to the construction of a model. To make reuse safe, it is necessary that models are augmented with information that enables a tool to safeguard against inconsistent usage of models. The first step in improving consistency is the addition of a documentation field. Unlike a comment, the documentation field belongs to a specific element in a model description, and

therefore, it stays associated to that element throughout the modeling and simulation process. Whereas the addition of documentation is oriented towards human interpretation, SIDOPS+ also provides means to specify information that can be automatically verified. This includes physical types which can be used to verify compatibility of equations and connections, and constraints on values for variables and parameters. Physical type consistency and constraints can be enforced automatically, without human intervention. Both the documentation field and physical types are illustrated in listing 7. This listing repeat a fragment from listing 5 and further specifies the parameter that specifies the sample interval. In the parameters section, we see that a physical type () has been added, and that the documentation field specifies that the meaning of this parameter is that of sample interval. This information can be preserved throughout the model processing, and be presented in a simulation package to assist the user in identifying the role of the parameters. In the constraints section, the obvious limitation that the sample interval must be positive is formulated explicitly. During further model usage, this constraint can be enforced by tools. Should the user enter a faulty value, the documentation field of the constraint can be used to present a user-friendly explanation of the cause of the problem. ... parameters real h “sample interval”; ... constraints h > 0 “sample interval must be positive”; end;

Listing 7: Annotated fragment of the model in listing 5 A typical source of inconsistency in models is the repeated entry of data that depends on the same information. Two different techniques are introduced in SIDOPS+ to handle this source of modeling problems. The first is the possibility to define libraries of declarations. These libraries contain generally usable declarations of constants (e.g. mathematical constants like pi and physical constants), look-up tables (e.g. data sheet information for actual devices), and custom functions. A fragment from such a declaration library is shown in listing 8. library system; ... constants real pi = 3.1415926536; real g = 9.81 ; ... end;

Listing 8: Declaration library The second technique to reduce model inconsistencies is to formulate dependencies explicitly. This is particularly important in the case of dependencies between parameters. Since the

304

Published in: Proceedings of ICBGM'97, 3rd International Conference on Bond Graph Modeling and Simulation, Phoenix, Arizona, January 12-15, 1997, SCS Publishing, San Diego, California, Simulation Series, Vol.29, No.1, ISBN 1-56555-050-1.

SIDOPS+ model structure leads to a relatively deep decomposition, it frequently occurs that parameters in different submodels are based on a single ‘physical’ parameter. This is worked out in listing 9. This listing shows the relevant parts to specify a mass in a gravity field. The bond graph model contains a submodel that represents the gravitational effect, and another submodel that represents the inertial effect of the mass. The parameters of both submodels are dependent on a single physical mass. This mass is declared in the submodel, and the dependency is expressed in the parameter relations section of the model. In the first relation, we specify that the force of the gravity submodel (grav:F) is equal to minus the ‘physical’ mass multiplied by the gravity constant. The gravity constant is imported from the library that is shown in listing 8. bond graph model vert_mass; ports p; submodels Se grav; I mass; ... connections ... parameters real m; constants from system import g; parameter relations grav:F = –m*g; mass:m = m; end;

Listing 9: Imported declarations and parameter relations

2.5 Openness In a practical engineering environment, multiple tools are used in combination. To minimize the effort of transferring models from one tool to another, it is preferable to have a common language that can be used to exchange model information. SIDOPS+ is intended to provide that openness. The key to openness is to have a language that is neutral, i.e. not biased towards a particular tool or domain of application. Although the design of SIDOPS+ is based on the SIDOPS language that was exclusively used by the 20-SIM modeling and simulation environment, the new language is free from toolspecific constructs, because the openness requirement has been taken into account throughout the language design. A special feature in SIDOPS+ is the tool specific field. This field can be used anywhere in a model description and can contain any information that is not captured by the SIDOPS+ language. Each tool specific field contains an identification of the information that follows, so that different tools can extract the information they can not store in SIDOPS+ format. This is illustrated in listing 10.

... submodels resistor R1 { color red }, R2 { color blue }; ...

Listing 10: Tool specific fields Tool specific fields can also be used to temporarily accommodate information that could become part of a future SIDOPS+ standard.

3 IMPLEMENTATION The introduction of a new language affects the whole suite of tools that is used in automated modeling and simulation. In this section, we will briefly discuss the current status of the introduction of SIDOPS+ in the 20-SIM software. The first step in the introduction of the new language is the design and formal specification of the language. The design of the language has been finished (Breunese 1996; De Jager 1996). A formal specification is available (Breunese and De Jager 1996), and a basic compiler has been built to verify the language design (De Jager 1996). To use the new features, the model editors have to be expanded to make use of the additional attributes and the new representations. A large number of ideas awaits implementation at this time. Thorough verification of the models and generation of simulation code is done in the model processor. Some of this work has been done as part of the construction of the compiler. Further work is currently performed. The last tool in the modeling and simulation cycle is the simulator. At this moment, a combined-system simulator is available (Broenink and Weustink 1996) that supports the aspects of SIDOPS+ that relate to simulator features. Summarizing, the last hurdle in the introduction of SIDOPS+ is the modification of the model editors and the model processor. This process should be finished in a matter of months. Since many of the features in the SIDOPS+ language can be implemented independently, the first features will become available shortly.

4 CONCLUSIONS Due to new developments in computer science, the possibilities of supporting the modeling process become greater. To keep up with the evolution of the possibilities, the languages used to describe the models have to be updated too. In this paper, we focus on modeling mechatronic systems. Although a variety of languages for the description of this class of systems already exists, none of them provides all services we find important. Therefore, we chose the most promising candidate (i.e. SIDOPS) as the basis for the design of a new language. This new language, SIDOPS+, supports all of the requirements we have formulated. Moreover, the language has openness built into it. It is not only suitable for use in the 20-

305

Published in: Proceedings of ICBGM'97, 3rd International Conference on Bond Graph Modeling and Simulation, Phoenix, Arizona, January 12-15, 1997, SCS Publishing, San Diego, California, Simulation Series, Vol.29, No.1, ISBN 1-56555-050-1.

SIM environment, but it is sufficiently generic so that it can also be used with other modeling packages. By providing hooks for information that cannot be formalized in the SIDOPS+ language itself, we provide a mechanism to include tool-specific data, and the same mechanism can be used to include data that may later be formalized into SIDOPS+ model descriptions. The SIDOPS+ language presented in this paper comes with a formal definition of the language syntax and its semantics. An implementation in the 20-SIM modeling and simulation software is currently being performed. We expect that SIDOPS+ will be exposed to usage in actual engineering problems in a matter of months. After gaining experience and possibly relieving growing pains, we intend to submit SIDOPS+ as an open standard. This is one of the aims of the OLMECO project that initiated the design of the SIDOPS+ language.

ACKNOWLEDGEMENTS The research described in this paper was partially supported by the European Union through its ESPRIT project. In project 6521 OLMECO (‘Open Library for Models of mEchatronic COmponents’), the University of Twente collaborates with PSA Peugeot Citroën and Imagine (France), Fagor and Ikerlan (Spain), BIM (Belgium), and ECN (Netherlands). The authors wish to thank Marc de Jager for his contribution to the design of the SIDOPS+ language and the implementation of the SIDOPS+ compiler (De Jager 1996).

Cellier, F.E. 1979. Combined continuous/discrete system simulation by use of digital computers: techniques and tools. PhD thesis. Swiss Federal Institute of Technology, Zurich, Switzerland. Cellier, F.E. and H. Elmqvist. 1993. “Automated formula manipulation supports object-oriented continuous-system modeling.” IEEE Control Systems 13, no. 2: 28-38. Controllab Products. 1996. 20-SIM Reference Manual, PC version 1.0. Controllab Products, Enschede, Netherlands. De Jager, M. 1996. Realization of the model description language SIDOPS+. MSc thesis no. 022R96. Control Laboratory, Department of Electrical Engineering, University of Twente, Enschede, Netherlands. De Vries, T.J.A. 1994. Conceptual design of controlled electro-mechanical systems, PhD thesis. University of Twente, Enschede, Netherlands. De Vries, T.J.A.; P.C. Breedveld; and P. Meindertsma. 1993. “Polymorphic modelling of engineering systems.” In Proceedings of the 1993 International Conference on Bond Graph Modeling and Simulation (San Diego, CA, Jan. 17-20),. SCS, San Diego, CA, 17-22. Mathworks, Inc. 1992. The student edition of MATLAB for MS-DOS or Macintosh computers. Prentice-Hall, Englewood Cliffs, NJ.

REFERENCES

Mitchell and Gauthier Associates. 1993. Advanced Continuous Simulation Language (ACSL) Reference Manual, Edition 10.1. Mitchell and Gauthier Associates, Concord, MA.

Breunese, A.P.J. 1996. Automated support in mechatronic systems modeling. PhD thesis. University of Twente, Enschede, Netherlands.

Top, J.L. and J.M. Akkermans. 1994. “Tasks and ontologies in engineering modelling.” International Journal of HumanComputer Studies 41, no. 4: 585-617.

Breunese, A.P.J. and M. de Jager. 1996. “SIDOPS+ language reference.” Technical report 023R96. Control Laboratory, Department of Electrical Engineering, University of Twente, Enschede, Netherlands.

Top, J.L.; A.P.J. Breunese; J.F. Broenink; and J.M. Akkermans. 1995. “Structure and use of a library for physical systems models.” In Proceedings of the 1995 International Conference on Bond Graph Modeling and Simulation (Las Vegas, NV, Jan. 15-18), SCS, San Diego, CA, 97-102.

Broenink, J.F. 1986. “SIDOPS: a bond-graph based modelling language.” In Complex and distributed systems: analysis, simulation and control, S. Tzafestas and P. Borne, eds. North Holland, Amsterdam, 81-86. Broenink, J.F. 1990. Computer-aided physical-systems modeling and simulation: a bond-graph approach. PhD thesis. University of Twente, Enschede, Netherlands. Broenink, J.F. and P.B.T. Weustink. 1996. “A combinedsystem simulator for mechatronic systems.” In Proceedings of the European Simulation Multiconference (Budapest, June 26), SCS, San Diego, CA, 225-229. Broenink, J.F.; J.W. Bekkink; and P.C. Breedveld. 1992. “Multibond-graph version of the CAMAS modeling and simulation environment.” In Bond graphs for engineers, P.C. Breedveld and G. Dauphin-Tanguy, eds. North-Holland, Amsterdam, 253-262.

306