An Object-Oriented Data Model for Multibody Systems M. Otter Institute for Robotics and System Dynamics German Aerospace Research Establishment (DLR), Oberpfaffenhofen

M. Hocke Computer Center of the University of Stuttgart (RUS)

A. Daberkow and G. Leister Institute B of Mechanics, University of Stuttgart

Abstract

An object-oriented data model is defined to describe parametrized multi body systems. A scheme to store the description of a multi body system on a database as well as a file format to store it on a data exchange file are directly derived from this data model. If a multibody system may be parametrized, it is e.g. possible to apply parameter optimization as a tool for synthesis and design.

1 Introduction

In this paper an object-oriented data model for multibody systems is described. This data model is the base of the multibody software package, developed in the research project "Dynamics of Multi body Systems" which was funded by the German Research Council (DFG) during 1987-1992. The structure of the software package is shown in Figure 1. A central database is used in order to store all the relevant data such as multibody system definitions or simulation results . Furthermore, the database serves as a standardized interface to exchange data between modules which are independent from each other. A more detailed discussion of the multibody system data model is given in [7, 8]. The realization of the software package is described in [3].

The object-oriented data model includes multibody systems consisting of rigid bodies connected by ideal joints and force elements, as well as measurement elements called sensors. The topology of body and joint connections is arbitrary, especially closed

19

W. Schiehlen (ed.), Advanced Multibody System Dynamics, 19-48. © 1993 Kluwer Academic Publishers.

20

-

I User Interface, CAD I I D

A I

I Formalisms I T A

I I Simulation J B

I I A

Visualization I s

E I I Design

I

'----

Figure 1: Structure of the DFG multibody system package

kinematic loops can be modelled. Force and torque interactions are possible between arbitrary bodies. Furthermore, a basic library of joint, force, and sensor elements is provided. Due to the object-oriented nature of the data model, this library is extendable by the user. No distinction is made between new elements added by a user and already existing ones in the library.

The multibody system data model has been extended with respect to several im­portant aspects. Wallrapp [13] has added classes to describe deformable bodies in modal representation. This representation includes higher order terms to allow the formulation of the "geometric stiffening" effect . Daberkow [2] has added classes to describe the geometric properties of multibody systems as needed for visualization and animation and extracts these data from a CAD-system.

The data model has three unique features as compared to commercially available multibody software packages: 1.) The data model is independent from a specific multibody algorithm or multibody program, respectively, and can therefore be used as a neutral format for the exchange of multibody system descriptions between different multibody programs. 2.) Multibody systems are described as input/output blocks to allow easy incorpora­tion in modelling, analysis, and design packages for e.g. connecting multi body systems with control units or other elements. This is a completely different view as usually utilized in closed multibody software, since the multibody system is no longer the central part of the modelling process but just one block among others. 3.) The data model is parametrized, i.e. each constant input data (e.g. mass, spring constant) can be given either a numeric or a symbolic value where the actual nu­meric value of a symbol can be defined later on. This important feature allows the utilization of synthesis methods to determine the actual values of symbols, e.g. by parameter optimization.

21

The multi body system data model is formally defined on the basis of a simple neutral object-oriented data model according to Ullman [12]. The main objective of this data model is the definition of a database scheme, i.e. the format of the data for the storage in a database and the integrity constraints between the parts of the data. As shown in this paper, such a data definition can equally well be regarded as a formal description of a file format. Therefore, the multibody data model not only describes a database scheme but a file format as well and allows an easy exchange of the definition of multibody systems via data exchange files .

2 A Neutral Object-Oriented Data Model

The discussion of different data models in [7] shows that engineering applications, such as multibody systems are described by an object-oriented data model in a natural and efficient way, contrary to e.g. a relational data model. Therefore, the data model for the description of multi body systems is based on the simple, neutral , object-oriented data model due to Ullman [12]. This data model is characterized by the following attributes:

1. Encapsulation: Generic operations are provided to access the data values of an object. The internal data structure of the object is completely hidden.

2. Object Identity: Different objects are distinguished by a unique ident~fier. Mod­ifications of the internal state and the data values do not affect the identity of the object .

3. Complex Objects: Complex objects are recursively defined, using elementary data types and existing object types as components. A complex object is an aggregation of several other objects with an explicitly defined structure.

4. Inheritance: Inheritance is useful to construct well defined type hierarchies. A derived class which is called subclass inherits all the components and methods of the superclass . New components and methods may be defined for the derived class. Existing methods may be redefined.

In an object-oriented data model, the structure of the objects and their behaviour are described by classes. A class description consists of two parts: the scheme description of the object type and the specification of the available methods, also called operations. Both aspects of a class are described in the following sections.

22

2.1 Object Types

The first part of a class description consists of the definition of the object type. At a basic level the data model supports the following elementary data types:

int real double char name

sname

dparam input

Integer value. Single precision floating point value. Double precision :floating point value. Character string of variable or fixed length. Special character string. A name must begin with a letter and may not have more than 8 characters. Unique identifier to address any component of the data model. A sname is implemented as a succession of names, each separated by an underscore. Parameter which either stores a name or a double precision value. The name of a time dependent input signal.

Furthermore, multi-dimensional arrays with fixed or variable length of the elementary data types are supported. New object types are recursively defined by applying the following rules according to Ullman [12]:

1. Let T1, .. . , Tn be elementary data types, then recordof (T1, ... , Tn) defines a composed object type. Each component of the record must be specified by a name and a data type. The component may be a single value or an array of variable or fixed length. The name of the component must be unique within the same object type. The following optional attributes are supported: lower and upper bounds, default value, physical unit, and short description text. See for example the class description of class body in Appendix A.

2. Let T1, ... , Tn be object types, then recordof (T1, ... , Tn) defines a complex object type. Each component of the record must be specified by a unique name, an object type, and an optional short description text. See for example the class description of class block.

3. Let T be an object type, then setof (T) also defines a valid object type. A set is an unordered collection of objects of class T. Any number of objects may be present in the set . Each object in the set must be specified by a unique name and an optional short description text. A set of objects does not necessarily define a new class, since a set may also be a valid component of a complex object . See, for example the component force of class member.

4. Let Tsup be an object type defined as a record according to the rules 1 or 2 de­scribed above and let T1, ... , Tn be object types or elementary data types, then recordof (subtypeof(Tsup), T1, ... , Tn) also defines a valid object type. The definition subtypeof(Tsup) states that a new object type is derived by inhe­ritance from the supertype T sup and shall be replaced by the record definition

23

of type T,up· The derived object type is called subtype. See for example class rigid in Appendix A. Class rigid is a subclass of class part. Therefore, class rigid inherits all components from class part.

Inheritance is used in the data model mainly for two reasons: First of all, inheritance supports the extension and modification of classes without the need to modify the source code of existing methods. Secondly, inheritance enables the introduction of new classes for specific problems, e.g. for frames, joints, and forces. This is shown on the example of class joint: whenever an object of class joint is required in the data model, an object of any class can be used which is directly or indirectly derived by inheritance from the superclass joint. Objects of other classes are rejected.

2.2 Methods

The second part of a class description consists of the specification of the available methode. The data model supports two groups of methods:

Administrative methods are used to manage and manipulate data objects and to access data values. At least the following operations are supported: access to objects in main memory (initialize new objects; delete existing objects; read and write components and data values; query attributes) , transfer of objects from database to main memory and vice versa, and manipulation of objects on database (delete objects; copy objects; rename objects; browse objects) . These operations are generic methods, since they are independent of the applicat ion and can be applied to objects of all classes. The generic methods are provided by the database system.

Class specific methods can be applied to objects of a specific class only. These me­thods are used to perform computations which depend on the application. Therefore, they can not be provided by the database system but must be implemented by the application engineer. Class specific methods are inherited from the superclass and may be redefined within the subclass.

As an example, joints connecting the parts of a multibody system are considered. Joints are represented by objects of class joint or any subclass which is derived from superclass joint. In superclass joint all operations are defined to implement a specific multibody algorithm, e.g. operations to determine the number of degrees of free­dom, to compute the position vector and the rotation matrix between frames, and to compute the relative velocity and the relative angular velocity between frames. The methods have to be redefined in all subclasses.

24

3 Data Model for Multibody Systems

In this chapter the object-oriented data model for multibody systems is explained shortly. In Appendix A the data model is rigorously defined by class descriptions. The data model is formulated to be used for the design and analysis of multibody systems, e.g. by dynamic simulation, linearization, or parameter optimization.

A multibody system is treated as a special case of a general input/output block. Such a block is introduced in the next section and is used as superclass for the multibody system data model in section 3.2.

3.1 Description of Dynamic Systems

The utilization of general purpose methods for the design and analysis of dynamic

systems requires a parametrized standard format, independent of a particular engi­neering domain. Such a description has to be parametrized, since every synthesis or

design method needs free parameters to deal with. The most important standard

format for dynamic systems is an input/ output block, see Figure 2. An input/output

P= initial const. condition s

u(t) block y(t)

data from tile or from database

Figure 2: Description of a dynamic system as input/output block.

block is a "black-box" description of a dynamic system, consisting of input signals u(t), output signals y(t), parameters p=const, and internal signals which depend on

the particular mathematical description of the block. Usually, a dynamic system

can be described mathematically in different forms, e.g. by explicit or implicit ordi­nary differential equations or by differential-algebraic equations . However, the input

signals, output signals, and parameters remain always the same.

The block description of a dynamic system allows the utilization of several important

analysis and design methods: the parameters of a block can be used in a parameter

study, parameter optimization, or sensitivity analysis. The input signals of a block

can be used in trajectory optimization. The input and output signals of a block can be used to connect the block with other blocks or to linearize the block equations.

25

In the data model the input/output properties of a block are described by an object of class block, see Appendix A. Class block consists of the components input, output, and param. Components input and output are objects of class signal. Class signal describes time signals by defining a name, a unit, and a short description text for every signal. The names of signals are used to uniquely identify a signal. Class param describes parameters by defining a name, a unit, a default value, a minimum value, a maximum value, and a short description text for every parameter.

Parameters can be independent or dependent ones. Only independent parameters can be assigned actual values later . The values of dependent parameters are always calculated from the actual values of independent parameters. The mathematical ex­pressions to calculate dependent parameters are stored in component expr of class param. If the equations of a dynamic system are generated symbolically, the ex­pressions to calculate dependent parameters are transformed to statements in the generated code. If the equations of a dynamic system are provided numerically, the expressions are interpreted and evaluated during execution, see [8].

The differential and algebraic equations of a block may be provided as FORTRAN

or C subroutines with prescribed interfaces, for example according to the neutral DSblock definition [9]. The subroutines containing the equations of a block can be implemented by hand but are usually generated by a program, e.g. by NEWEUL for multibody systems [4, 5].

3.2 Description of M ultibody Systems

Multibody systems consist of material bodies interconnected by constraint elements (joints) and coupling elements (forces), see [11 J. They are well qualified for the dynamical analysis of machines , mechanisms, robots, and all kind of vehicles.

Multibody systems are treated here as special input/output blocks, i.e. they have all the properties of a block and additional ones. Therefore, multibody systems can be utilized whenever a block is required. In the data model, multibody systems are described by class mbs. This class is derived from class block by inheritance, i.e. all the components of class block are also components of class mbs. A multibody system is essentially composed of the two basic elements: part and interaction element, see Figure 3.

A part is a collection of coordinate systems, also called frames. If the part is a rigid body, all frames on the part do not move relative to each other. If the part is a deformable body, the frames on the part move according to the deformation of the body. Parts may have mass and inertia properties but can also be used to describe massless bodies, mass points, or moving reference systems. The inertial system or the environment, respectively, is a special part which is always defined by the name inertial .

26

frame

/ /

............ "" interact

part

Figure 3: Basic elements for the description of a multibody system

An interaction element acts between one frame on a first part and one frame on a

second part. Three types of interaction elements are distinguished: Joint elements restrict the relative motion between the two frames, force elements exert forces and

torques between the two frames, and sensor elements are used to determine kinematic quantities of the relative motion between the two frames .

On every part a unique frame is defined to be the part reference frame. Often one of the frames of an interaction element or the center of mass of the part are used

as part reference frame. Additional frames on a part are defined with respect to a reference frame which is either the part reference frame or another already defined frame. In Figure 3, every frame is connected with its corresponding reference frame by a dashed line with an arrow. By definition, the frame reference topology on a part is always a tree structure with the part reference frame as the root .

Parts, frames, and interaction elements are identified in the same way by unique names. The name of a part or an interaction element must be unique with respect to all other parts or interaction elements of the multibody system. The name of a

frame has to be unique with respect to all other frames on the same part.

Class mbs represents the decomposition of a multi body system into the basic elements:

due to inheritance, class mbs consists of the components of class block and additionally

of the components global, part, and interact. Component global contains all the

data needed for the overall multibody system, at present only the definition of the

gravitational acceleration. Component part is a set of objects of class part and contains all the part descriptions of the multibody system. Similarly, component

interact is a set of objects of class interact and contains the descriptions of all the

interaction elements of the multibody system. The object hierarchy following from

27

this decomposition is shown in Figure 4.

mbs

Input output param global part Interact

I I I gravity setof(part) setof(lnteract)

I I

frame body connect member

I setof(frame) joint force sensor

I setof(force) set of( sensor)

Figure 4: Object hierarchy of the multibody system data model

Description of Parts

An object of class part defines a massless rigid body as a collection of one or more frames. Examples include a body with vanishing inertia, the inertial system, or a moving reference system. Class part has only the component frame which is a set of objects of class frame. With the except~on of the part reference frame, all the other frames on the part are objects of the set and are identified by their corresponding names in the set. The part reference frame is referenced by a blank string.

Class frame is used as a superclass for the definition of different classes to describe coordinate systems. Class frame has only the component rframe in which the name of the reference frame is stored. Therefore, the position of an object of class frame is identical to its reference frame . Class frame has operations to calculate e.g. the position vector and the rotation matrix from the reference frame to the frame. De­pending on the implementation, these operations must be redefined in the subclasses of class frame. Several subclasses are shown in Appendix A, e.g. class point defines a frame which is translated relative to its reference frame and class cardan defines a frame which is translated and rotated relative to its reference frame, whereby the rotation is described by roll, yaw , and pitch angles . Every user can define and add new subclasses of class frame.

Rigid bodies are parts with mass and inertia properties and are described by class rigid. Class rigid is a subclass of class part. It has all the characteristics of the superclass and additionally the component body of class body. The mass, the center

28

of mass and the inertia tensor of the rigid body are stored in an object of class body. The center of mass is defined by the origin of an already existing frame. The inertia tensor is defined by its six independent elements and by the name of a frame with respect to which the tensor is defined.

Deformable bodies in modal representation are defined by class modal. This extension of the data model is due to Wallrapp [13]. Class modal is a subclass of class part and has the restriction that the frames on such a part have to be directly or indirectly derived from class node. Class node is a subclass of frame and describes a material point in the modal representation.

Description of Interaction Elements

An object of class interact describes the interaction between a frame A on one part and a frame B on another part, see Figure 3. Class interact has the components connect and member. The names of the two parts and two frames of the interaction element are stored in component connect. Component member of class member consists of the components joint, force and sensor. Component joint is of class joint and defines the restrictions of the relative motion of frame A with respect to frame B imposed by the interaction element . Component force is a set of objects of class force and defines the forces and torques exerted by the interaction element. Finally component sensor is a set of objects of class sensor and defines the kinematic quantities of the relative motion of frame B with respect to frame A to be computed and resolved in a desired frame . Similar to the frames on a part, the names of the force and sensor elements must be unique with respect to their corresponding set.

Comparable to class frame, the classes joint, force, and sensor are used as superclasses of more specific elements. The classes joint, force, and sensor do not have components by their own but define methods which have to be redefined in the subclasses. Appen­dix A shows several subclasses of these classes. For instance, class revolute defines a revolute joint, class sphere defines a spherical joint, and class springt defines a translational spring force element .

Class revolute has the components aaxis, baxis, and rangle. Component aaxis defines the axis on frame A and component baxis the axis on frame B which lie in the axis of rotation of the revolute joint. Component rangle stores the value of the rotation angle of the revolute joint in the reference configuration of the joint. If components aaxis and baxis have the same value, frame A and frame B coincide in the reference configuration. Usually, the data of a revolute joint are given in the following way: the multi body system is moved into a specific position, where frame A and frame B are defined in such a way that they coincide and that one of the frame axes is the rotation axis of the revolute joint. In this configuration, the value of the rotation angle is usually zero. Other joint types are defined in a similar way.

Class springt has the components c and sO. Component c is the spring coefficient

29

and component sO is the unstretched spring length. This force element exerts a line force f = c * (s- sO) between the origins of frame A and frame B, where s is the distance between the two origins .

3.3 Integrity Constraints

The data of a multibody system stored on database must satisfy several integrity constraints on different levels. Elementary integrity constraints relate to a single object and are defined in the class descriptions. The database management system guarantees that only objects according to their class description can be generated, modified, and stored on database . Such integrity constraints include the correctness of the data types and object types as well as lower and upper bounds for numeric values. Further integrity constraints exist for the multibody system data model, which cannot be expressed by class descriptions. Therefore, the following conditions are checked by special methods, see [3]:

• Class connect: An interaction element has to connect different parts, i.e. com­ponent apart and bpart of class connect must have different values.

• Class joint: Optionally, only one joint is allowed for the connection of two parts, since most multibody algorithms require this condition.

• Classes part and joint: The multi body system must have a" complete kinematic connection structure", i.e. starting from the inertial system, all parts must be reachable via the part-joint connections.

• Object references: Referenced objects must exist. For instance, if the name of a frame is stored in an object of class connect, this frame object must be present.

• Class body: Numerically, the inertia tensor must be positive semidefinite.

• Redundant constraints: The data model allows the definition of multibody sy­stems with redundant constraints, where the constraint forces cannot be calcu­lated. An operation is provided [3] to analyse the topology even of overdetermi­ned multi body systems (e.g . computation of the number of degrees of freedom for each kinematic loop).

• Noncompatible topology: The data model allows the definition of multibody systems with kinematic loops, where the kinematic connection structure cannot be realized. An operation is provided [3] to determine consistent positions of the multi body system. This operation will complain, if the connection structure is contradictory.

30

3.4 Extensions

The multibody system data model has been extended in several directions. Wall­rapp [13] has added classes to describe deformable bodies in modal representation. This representation includes higher order terms to allow the formulation of the "geo­metric stiffening" effect .

Daberkow [2] has added classes to describe the geometric properties of multibody systems as needed for high speed visualization and animation and extracts these data from a CAD-3D-system. Modules for the animation of multi body systems using this enhancement and the basic data model have been realized by Daberkow [2] and Rocke [3].

revolute

Lp

Figure 5: Planar face model and parametrized shapes

In the data model, geometric properties of parts are described by a planar face model. This kind of geometry model is used for the following reasons: Commercial CAD-3D systems internally use different geometry models and data formats, e.g. Constructive Solid Geometry or Boundary Representation. These different CAD-3D models are easy to convert into a planar face model. Furthermore, basic graphic packages such as PHIGS, Iris GL, FIGARO+ and GMR3D use the planar face model because it is well suited for high speed visualization. Daberkow [2] realized a special geometry editor to generate geometry data of parts directly and an interface module to extract it from a CAD-3D system.

Class g3body describes the geometry of a body (planar faces, vertices, and edges) and the drawing attributes (colour, material) . All vertices of a face are resolved with respect to the part reference frame of the corresponding part. Objects of classes frame, joint, force and derived subclasses are graphically described by parametrized shapes. For example, class g3frame is derived from class frame and stores the attributes of the frame colour and the frame axis length. In Figure 5 the parametrized shapes of an object of class g3frame and g3rev are shown in a wireframe representation. Finally, global graphic information, such as colour map, material table, global view and projection parameters are stored in an object of class g3global.

31

4 File Representation of the Data Model

The r:ata model for multibody systems describes both, a database scheme for an object-oriented database and a file format for a data exchange file. Below, the file format is described shortly, in Appendix B it is defined in context free grammar [1]. The grammar is formally derived from the multibody system class descriptions using a few simple rules.

A data exchange file consists of keywords, numeric and symbolic values and special characters. The name and the structure of the keywords, also called commands, is derived from the object hierarchy of the data model, see Figure 4. A keyword leads one step down in the hierarchy, while command 'go' causes one step up. A data exchange file may be written in free format, no distinction is made between uppercase and lowercase letters. All characters following two minus signs ( --) are regarded as comments and are ignored until the end of the line.

Dynamic levels are characterized by set of( ... ) in Figure 4. The special commands 'new', 'copy' and 'link' introduce additional commands on such a level. Whenever a new command is generated, a corresponding new object is created and initialized with its default values as defined by the class description. With 'new <name> = <class>' the new command <name> is introduced on this level and the input branches into the commands of class <class>. With 'copy <namel> <name2>' a complete copy of all objects of <namel> is made and will be accessible with the new command <name2>. With 'link <namel> <name2>' the new command <name2> is introduced. It is synonymous to <namel>. This means that the two objects <namel> and <name2> share exactly the same data.

When one of the final commands of the tree hierarchy in Figure 4 is reached (e.g. joint), input is done according to the specific class of the object on this level. Sca­lars are given by '<command> = <value>', where <command> is the name of the component in the class description and <value> is a numeric or character value according to the FORTRAN syntax. Example:

part

go

new arm1 = rigid body

mframe = 'CM' go

go

new object arm! (of class rigid)

If the class description requires a variable of type dparam, i .e. a numeric value or the name of a parameter, two components/commands are present. One component

32

stores the numeric value and the other component stores the character value. The numeric value is only valid if a blank string is stored as parameter, otherwise the character value is valid. The corresponding commands are 'd<comp>' for the nume­ric component and 1 s<comp> 1 for the character component, where <comp> is the name of the component in the class description (e.g. dmass and smass for component mass). These rules have been defined, since database systems usually do not support a mixed data type like dparam. Example:

part

go

new arm! = rigid body

dmass = 1.5 go

go

Arrays are defined according to a Matlab type syntax [6] . If an array is of type dparam the same rules as for scalars apply; i.e. a numeric and a character array are actually present. An array has to be given either in the form 1 <com> <range> = <value> 1 or in the form '<com> <range> = <matrix> 1 , where

\

<com> is the name of the array. <range> is an optional range of the array in a Matlab type syntax (e.g. "(3)",

"(3,3:5)" or "(2:4,:,4)"). <value> is one scalar value. All elements of the array selected by <range> will

be set to <value> . <matrix> is a 2-dimensional array, where the elements of the matrix are given

row-wise. A row ends with end-of-line or with a semicolon (;). Array elements are separated by blanks or by comma(,). The beginning of the matrix is characterized by a left bracket ( [) and the end of the matrix by a right bracket (J ).

A one-dimensional array can be given either as row or as column matrix. A three­dimensional array can only be defined using <range>. Examples:

dorigin [0 0 2 . 5] from class body sinertia [) J11)' ) J22'' 'J33'' ' '] from class body MO [1.E-3, 0 from class taylor

0 2.E-3] M1(1 ,2, 1) 3.4 from class taylor M1(2:3,: ,2) [ 0 -0.23 from class taylor

0 . 23 . 0

33

5 Example

The file representation of the multibody system data model is demonstrated by an example. In Figure 6 a spatial four bar mechanism is shown consisting of four bars, connected to each other by two revolute joints, one universal joint, and one spherical joint. The environment is treated as one bar. It is assumed that the data of the joints, of bar 1, and of bar 3 are fixed, whereas bar 2 is parametrized, such that the geometric shape of this bar can vary and is therefore open to a design process.

F2(on bar11 F3(on bar2)

Figure 6: Spatial four bar mechanism

In the revolute joint of bar 1 an external torque is present which drives the mechanism. As output signals, the angle and the angular velocity of the revolute joint of bar 3 are used. The file description of this multibody system is given on the next two pages.

----

----

--P

aram

etri

zed

fo

ur

bar

mec

hani

sm -

----

----

--

inp

ut

nsi

g

nam

e u

nit

d

esc

r g

o

ou

tpu

t n

sig

na

me

un

it

desc

r

outn

ame

go

par a

m

nsi

g

nam

e d

esc

r

go

un

it

typ

e

defa

ult

e:

z:pr

(3:)

inp

ut

sig

nals

1 'T

DR

IVE

' '11

1m'

'Dri

vin

g t

orq

ue

of

fou

r b

ar

mec

hani

sm'

ou

tpu

t si

gn

als

2 [

'QO

UT

', 'Q

DO

UT'

]

[ 'r

ad

' ,

'rad

' ]

[ 'O

utp

ut

ang

le o

f fo

ur

bar

mec

hani

sm'

'Fir

st

deri

vati

ve o

f Q

OU

T'

] [

inte

ract

_b

ar3

_m

emb

er_

join

t_q

in

tera

ct_

bar

3_

mem

ber

_jo

int_

qd

par

amet

ers

(sy

stem

co

nst

an

t)

5 [ 'L

2',

'R

2',

'K

2',

'C

K2

',

'12

' ]

[ 'L

eng

th o

f b

ar

2'

'Rad

ius

of

bar

2'

'mas

s o

f b

ar

2'

'cen

ter

of

mas

s o

f b

ar

2'

'pri

ncip

al

mom

ent

of

inert

ia o

f b

ar

2'

] [

'm'

, 'm

' ,

'kg

',

'm',

'k

g m

••2

' ]

[ 2

• 2

' -2

'

-2

' -2

]

[ 0

.4,

0.0

1,

0 '

0 '

0]

[ 'P

I•R

2•R

2*

L2

•7.6

E3

' ,'L

2/2

','K

2*

L2

•L2

/12

']

glo

bal

go

gra

vit

y

dd

irg

rav

d

val

gra

v

go

[0,

-1.

0]

9.8

1

part

n

ev I

IIIER

TIA

L fr

ame

part

--

inert

ial

syst

em

new

F1

=

car

dan

d

ang

le

= [0

, 4

. 188

7902

, 0

] --

240

deg

go

ne

w F

4 =

car

dan

d

ori

gin

= [0

, 0

• 0

. 4]

dan

gle

=

[0,

1. 0

4719

755,

0

] --

60 d

eg

go

go

go

n

ev B

AR1

=

rig

id

--fi

rst

bar

go

fram

e n

ev F

2 =

poin

t d

ori

gin

= [

0,

0. 2

, 0

] g

o

nev

CK

= po

int

do

rig

in =

[0,

0.1

, 0

] go

g

o

body

go

dmas

s m

fram

e d

inert

ia

ifra

me

0.4

78

'CK

' [0

. 001

6,

0,

0.0

01

6,

0,

0,

0]

'CK

'

..., """

new

BA

R2

= r

igid

--

seco

nd

bar

(par

amet

rize

d)

go

tram

e ne

w

F3

= p

oin

t so

rig

in =

['

',

'1

2',

' ']

go

ne

w

CK

= p

oin

t so

rig

in =

['

',

'C

K2

', '

']

go

go

body

go

smas

s m

tram

e sin

ert

ia

itra

me

'K2

' 'C

K'

[I J

2' 1

'CK

' 'J

2'

J J

J '

']

lin

k B

AR1

BA

R3

--b

ar

3 is

id

en

tical

to b

ar

1 go

inte

ract

--d

eti

ne i

nte

racti

on

s b

etw

een

part

s ne

w

JREV

1 =

in

tera

ct

go

con

nec

t ap

art=

'IH

ER

TIA

L',

atra

me=

'F1

' b

par

t='B

AR

1'

btr

ame=

' '

go

mem

ber

go ne

w jo

int

aax

is

bax

is

torq

ue

go

rev

2

3

--re

vo

lute

jo

int

3 'TO

RQ

UE'

go ne

w

JUH

IV

= i

nte

ract

con

nec

t ap

art=

'BA

R1

',

atra

me=

'F2

' b

par

t='B

AR

2',

b

tram

e='

' go

m

embe

r ne

w jo

int

= u

niv

erse

--

un

ivers

al

join

t aax

is

= 3

b

axis

=

1

go

go

go

new

JR

EV2

= i

nte

ract

con

nec

t ap

art=

'IH

ER

TIA

L',

afra

me=

'F4

' b

par

t='B

AR

3'

bfr

ame=

' '

go

mem

ber

new

jo

int

= r

ev

olu

te

--re

vo

lute

jo

int

aax

is

= 3

b

ax

is =

3

go

go

go

new

JS

PBER

E =

in

tera

ct

con

nec

t ap

art=

'BA

R3

',

bpar

t='B

AR

2 at

ram

e='F

2'

btr

ame=

'F3

'

go go

m

embe

r ne

w

join

t go

sp

her

e,

go

--sp

heri

cal

join

t

w

'-"

36

6 Implementation of the Data Model

The object-oriented data model for multibody systems was implemented, as des­cribed in [3], by the Computer Center of the University of Stuttgart (RUS) using RsYST. RSYST is an open and modular software system for the development of large scientific and engineering application programs, see [10]. It provides several components, e.g. object-oriented database system, graphical user-interface, dynamic memory-management, error-handling system, and output system. All components are accessible through a monitor control program by the user and through a com­plete set of programming interfaces by the application engineer.

c.t..nss acm Sl'tnSS : U:1J OMSS : 1.000000000000 (ksJ )I[AA>!(

SINERilA: {6) (k.-.21 I.

umo•t1111t

.,.a.., or P•nt •B&IIo of pert ~ or ce,..ter of ... .,::;~ tr-ll'l.r'\..10 t<Ct~aor<U1.I22 .133.112.113 .123)

WriU eMnUon deu to f tle

~ ~ Gener•te g.en.c:r l e ~ubr~ut1nc.J

l:!!!!:JIE!!!!!I Print d•\ • or • . b.,

·r

1 2 Ill <I '5 8 7 8 9 10 11 12

J:HrERACT _JR£'1'2

_t:OHNI:CI ""'"EHBEA_

JIARI ..I!OOEH

_BODY JRAH£_

JPIERIIAl ..JOO'I'

..0001 ..800'1' JAAKL

..A002

Figure 7: Screen hardcopy of the multibody system package

The data model has been realized in the following way: first of all, a scheme descrip­tion for RSYST has been defined according to the class descriptions in Appendix A. It defines the data objects and the database structure to store a multi body system on database. Furthermore, methods to operate on multibody systems have been defined and realized, see [8]. In particular , a window-oriented module to edit the data objects of a multibody system on database has been implemented. This module is also used to parse a data exchange file in the format as described in chapter 4 and to generate the corresponding objects on database.

37

In Figure 7, a screen hardcopy of a typical session with the multi body software package is shown. The lower left part of Figure 7 shows the input window to select modules and commands, the right part shows the database browser while the upper left part shows a listing of one of the multi body system objects in the output window.

References

[1] Aho, V.A.; R. Sethi; J.D . Ullman: Compilers. Principles, Techniques and Tools. Addison-Wesley, 1987. German edition: Compilerbau. Addision-Wesley, 1988.

[2] Daberkow, A. : Zur CAD-gestutzten Modellierung von Mehrkorpersystemen. Dissertation, Stuttgart, 1993.

[3] Rocke, M.; R. Ruhle; M. Otter: An Open Software Environment for the Analysis and Design of Multibody Systems. Separate contribution in this volume.

[4] Kreuzer , E.; W. Schiehlen: NEWEUL - Software for the Generation of Symboli­cal Equations of Motion. Multi body Systems Handbook, edited by W. Schiehlen, Springer-Verlag, 1990.

[5] Leister, G.: Beschreibung und Simulation von Mehrkorpersystemen mit geschlos­senen kinematischen Schleifen . VDI-Fortschrittsberichte, Reihe 11, Nr. 167, 1992.

[6] Mathworks Inc: Pro-Matlab User Manual, South Natick, Mass., 1989.

[7] Otter, M.; M. Rocke; A. Daberkow; G. Leister: Ein objektorientiertes Datenmo­dell zur Beschreibung von Mehrkorpersystemen unter Verwendung von RSYST .

Universitii.t Stuttgart, Institut B fur Mechanik, Institutsbericht IB-16, Mii.rz 1990.

[8] Otter, M.; M. Rocke; A. Daberkow; G. Leister: Schnittstellen fur ein objektori­entiertes Datenmodell zur Beschreibung von Mehrkorpersystemen. Universitii.t Stuttgart, Institut B fur Mechanik, Institutsbericht IB-20, August 1991.

[9] Otter, M.: DSblock: A neutral description of dynamic systems. Version 3.2. DLR Oberpfaffenhofen, TR R81-92, May 1992.

[10] Ruhle, R.: RSYST- Ein Softwaresystem zur Integration von Daten und Pro­grammen zur Simulation wissenschaftlich-technischer Systeme. Rechenzentrum der Universitii.t Stuttgart , RUS-5 , Mii.rz 1990.

[11] Schiehlen, W.: Technische Dynamik. Teubner Verlag, Stuttgart, 1986.

[12] Ullman, J. D.: Principles of Database and Knowledge-Base Systems, Volume 1. Computer Science Press, 1988.

[13] Wallrapp, 0.: Standard Input Data of Flexible Members in Multibody Systems. Separate contribution in this volume.

38

Appendix A: Classes of the Data Model

The input/output signals and the parameters of a dynamic system are defined in class block.

class: block

name class description of component

input signal input signals

output signal output signals

par am par am parameters (constants of system)

Class signal defines general time dependent signals.

class: signal

name type min maz default unit description of component

nsig int 0 0 number of signals

name name (nsig) names of signals

unit char (nsig) ) ) units of signals ~

descr char (nsig) ) ) descriptions of signals ~

Class param describes the system parameters of the dynamic system. Each parameter has a physical unit, lower and upper boundaries, a default value and may be described by an arithmetic expression. Component type defines the interpretation rule of the parameters.

type> 0 type< 0 ltypel = 1 ltypel = 2 ltypel = 3 ltypel = 4

The parameter is an independent parameter, component expr is ignored. The parameter value has to be evaluated by computing the expression. The lower and upper bounds min and max are ignored. The lower bound min will be checked, the upper bound max is ignored. The upper bound max will be checked, the lower bound min is ignored. The lower and upper bounds min and max will be checked.

An expression in component expr has t o be a valid FORTRAN 77 term consisting of the following basic elements: Operators+, - , *• /, **• parenthesis, numerical integer­' real-, or double precision-constants (e.g. 2, 2.0, 2.0EO; note that all constants are internally stored as double precision values), names of independent or already defined dependent parameters, and the FORTRAN intrinsic functions ABS, SQRT, EXP, LOG, LOG10, SIN, COS, TAN, ASIN, ACOS, ATAN, SINH, COSH, TANH.

39

cla!!: par am

name type min maz default unit de!cription of component

np int 0 0 number of parameters

name name (np) names of parameters

unit char (np) , ,

units of parameters ~

type int (np) -4 4 1 types of parameters

min double (np) 0. minimum values of parameters

max double (np) 0. maximum values of parameters

default double (np) 0. default values of parameters

expr char (np) , , expressions for dependent parameters ~

descr char (np) , , descriptions of parameters ~

A multi body system is a special instance of a general block, hence class mbs is derived from class block. Class mbs inherits the input/output signals and the system para­meters. Special components for multibody systems are global, part and interact.

clau: mbs I name cla5s de5cription of component

subclassof (block)

global global global properties of mba

part setof (part) parts of mbs

interact setof (interact) interactions between parts

The relationship between the output signal of a mbs element and the corresponding external output signal is defined in class mbsout. Instead of class signal, this class has to be used in component output of class block.

clau: mbsout

name I type I min I maz I default I unit I de!cription of component

subclassof (signal)

mbsname lsname (nsig) I I I I I external output signals

of mbs-elements

The global characteristics of a multibody system are defined in class global. Currently it has only the component gravity.

clau: global

name I cla55 de!cription of component

gravity I gravity gravitational acceleration

40

Class gravity defines the gravitational acceleration.

clau: gravity

name type min maz default unit de8cription of component

valgrav dparam 9.81 mfs2 value of gravity

dirgrav dparam (3) 0., 0., -1. direction of gravity

gframe char ' ' frame on part inertial, ~

vector dirgrav is resolved

A part is a collection of frames.

cla88: part

name I clas8 I description of component

I frame I setof (frame) I frames on the part

The position and orientation of a frame is described relative to a reference frame on the same part . An object of superclass frame is identical to its reference frame. A reference frame with a blank name characterizes the part reference frame.

clau: frame

name type min maz default unit description of component

rframe name ,

' name of reference frame ~

on the same part

Usually a frame is translated and rotated relative to the reference frame. To support different frame descriptions, classes point, cardan, euler, framegen and node are deri­ved from superclass frame . Class node is used to describe nodes of deformable bodies in a modal representation, see [13]. Class point defines a coordinate system which is translated relative to the reference frame.

de8cription of component

origin of frame

A frame of class cardan is translated and rotated relative to the reference frame. The rotation is described by cardan angles.

clas8: cardan

name I type I min I maz I default I unit I de8cription of component I subclassof (point)

angles I dparam (3) ~-2-lr I 27r I 3 * 0. I rad I cardan angles (axle sequence 1,2,3)

41

A frame of class euler is translated and rotated relative to the reference frame. The rotation is described by euler angles.

clau: euler

name I type I min I maz I default I unit I description of component

subclassof (point)

angles I dparam (3) ~-27r I 27r I 3 * 0. I rad I euler angles (axle sequence 3,1,3)

A frame of class framegen allows the user to define the sequence of elementary rota­tions.

class: framegen

name type mm maz default unit description of component

subclassof (point)

axleseq int (3) -3 3 1, 2, 3 axlesequence of elementary rotations

angles dparam {3) -27r 27r 3 * 0. rad rotation angles

Class rigid is derived from class part and describes rigid bodies.

description of component

mass properties of the part

class: body

name type min maz default unit description of component

mass dparam 0. 0. kg mass of part

mframe name ' ' name of center of mass frame ~

inertia dparam (6) 6 * 0. kgm2 inertia tensor (Iu, !22, Iaa, !12, I1a, ha)

iframe name ' ' name of inertia tensor frame ~

Class modal describes a deformable body using the modal representation, see [13] . All frames of an object of class modal must be directly or indirectly derived from class node. Subclass modal and the additional classes of the components (classes node,

refmod and taylor) are described in [13] .

42

Interactions between two coordinate systems on different parts are described by class interact.

clau: interact I name clau description of component J connect connect frames to be connected I member member connecting element I

The two connected coordinate systems are defined in class connect. They have to be on different parts.

clau: connect

name type min maz default unit description of component

apart name name of apart

aframe name , ,

name of aframe on apart ~

bpart name name of bpart

bframe name , , name of bframe on bpart ~

Class member defines the type of the interaction. Between two coordinate systems, one joint, several force elements, and several sensors are allowed.

class: member

name class description of component

joint joint joint element on interact object

force setof (force) force elements on interact object

sensor setof (sensor) sensor elements on interact object

A joint connects a coordinate system on a first part ( = aframe) with a coordinate system on a second part ( = bframe). The motion between both coordinate systems is no longer independent. Specific classes for joints, see Figure 8, must be derived from superclass joint which has no components.

class: joint

The data model supports a set of predefined joint classes which are derived from superclass joint.

43

Figure 8: Different types of joints as subclasses of class joint.

Class revolute describes a simple revolute joint.

cla8s: revolute

name type min maz default unit description of component

subclassof (joint)

aaxis int - 3 3 1 axis of rotation on aframe

baxis int -3 3 1 axis of rotation on bframe

rangle dparam -271" 271" 0. rad rotation angle offset

Class translat describes a translational joint.

clau: translat

name type min maz default unit description of component

subclassof (joint)

aaxis int -3 3 1 axis of translation on aframe

baxis int -3 3 1 axis of translation on bframe

dist dparam 0. m translation distance offset

44

Class cylinder describes a cylindrical joint.

cla~~: cylinder

name type mtn maz default unit description of component

subclassof (joint)

aaxis int -3 3 1 cylinder axis on aframe

baxis int -3 3 1 cylinder axis on bframe

rangle dparam -271' 271' 0. rad rotation angle offset

dist dparam 0. m translation distance offset

Class universe describes a universal joint.

cla~~: universe

name type min maz default unit de~cription of component

subclassof (joint)

a axis int -3 3 1 first universal axis on aframe

baxis int -3 3 1 second universal axis on bframe

ranglel dparam -271' 271' 0. rad first rotation angle offset

rangle2 dparam - 271' 271' 0. rad second rotation angle offset

Class sphere describes a spherical joint.

clau: sphere

name I type I min I maz I default I unit I de~cription of component

subclassof (joint)

axleseq I int (3) I -3 I 3 11, 2, 3 1 I axleseq. of elementary rotation

rangles I dparam (3) I -271' I 271' I 0. I rad I offset of rotation angles

Class planar describes a planar joint.

cia~~: planar

name type min maz default unit de~cription of component

subclassof (joint)

aaxis int -3 3 1 plane perpendicular axis on aframe

baxis int -3 3 1 plane perpendicular axis on bframe

rangle dparam -271' 271' 0. rad rotation angle offset

distl dparam 0. m first translation distance offset

dist2 dparam 0. m second translation distance offset

Class jointfix describes a joint with zero degrees of freedom.

class: jointfix

name I type I min I maz I default I unit I description of component

subclassof (joint) no components

Class r3t3 describes a joint with six degrees of freedom.

class: r3t3

name type min maz default unit description of component

subclassof (joint)

axleseq int (3) -3 3 1, 2, 3 axleseq. of elementary rotations

rangles dparam (3) -271" 211" 3 * 0. rad offset of rotation angles

rpos dparam (3) 3 * 0. m offset of translational coordinates

45

Class jointgen allows an easy description of several standard and non-standard joints.

class: jointgen

name type min maz default unit description of component

subclassof (joint)

axleseq int (3) -3 3 1, 2, 3 axleseq. of elementary rotations

rotflg int (3) - 1 1 3*0 rotation blocked (0) or free (-1/1)

transflg int (3) -1 1 3*0 translat. blocked (0) or free (-1/1)

rangles dparam (3) -271" 271" 3 * 0. rad offset of rotation angles

rpos dparam (3) 3 * 0. m offset of translational coordinates

Classes rev2 and trans2 are revolute and translational joints with applied forces. These classes are especially designed for applications in robotics .

I class: rev2

I name I type I min I maz I default I unit I description of component

l subclassof (revolute)

I torque I input I I I I Nm I torque along axis of rotation

I class: trans2

I name I type I min I ma:t I default !unit I description of component

I subclassof ( translat)

I force I input I I I I N I force along axis of translation

Forces and torques between a coordinate system on a first part ( = aframe) and a coordinate system on a second part ( = bframe) are described by class force. Problem

46

specific classes for forces and torques must be derived from superclass force. Class force has no components.

class: force

name I type I min I maz I default I unit I description of component

no components defined

Class springt describes a simple translational spring.

class: springt

name I type I min I maz I default I unit I description of component

subclassof (force)

c I dparam I 0. I I I N/m I spring constant

sO J dparam J 0. I l 0. I m J unstretched spring length

Class dampert describes a simple translational damper.

description of component

damper constant

Class f3t3 describes a general force and torque acting between two frames .

class: f3t3

name type mm maz default unit description of component

subclassof (force)

force input (3) ' ' N force on aframe ~

torque input (3) ' ' Nm torque on aframe ~

abframe int 0 2 0 frame, vectors are resolved

0/1/2: resolved in inertial/ aframe/bframe)

Class sensor describes measurement elements which are used to compute relative kinematic quantities between a coordinate system on a first part and a coordinate system on a second part. Problem specific measurement classes must be derived from superclass sensor. Class sensor has no components.

description of component

Class relative describes a sensor element which calculates the relative position, ori­entation matrix, velocity, angular velocity, acceleration, and angular acceleration

47

between the two frames of the interaction elements and transforms the vectors in a desired frame on any part.

cla88: relative

name type min maz default unit de8cription of component

in part name name of part of frame inframe

inframe name ' ' name of frame, vectors are resolved ~

Appendix B: Grammar of the Data Exchange File

The syntax of the data exchange file format can be described in a context free gram­mar. This grammar is formally derived from the class descriptions of Appendix A, see for example [1] for the nomenclature. Italic words are non-terminals , boldface words are terminals, eol is "end-of-line", eof is "end-of-file" and "*" is zero-or-more-times.

1. A class T = recordof (subtypeof(Tsup), T1, . . . , Tn), where T1, ... , Tn are object types, leads to the productions:

Tclau -t (Tcomp Tclass )ITcomp Tcomp -t TSUPcomp iTldef l · .. ITndef Tidef -t Ti eoc Ticlau go eoc (i = 1, 2, .. . , n) eoc -t blank* ( blank I, I; I = I eol ) blank* ( blank* eol)*

2. A component Tset = setof (T) leads to the productions:

T •• t T.etcomp Tnew Tcopy Tlink Tel em

Tclaue• objectname classname name

-t ( Tsetcomp Tset) I Tsetcomp -t Tnew iTcopy iTlink iTelem ---> new eoc obj ectname classname Tctaue• go eoc ---> copy eoc objectname objectname ---> link eoc objectname objectname ---> obj ectname Tclaue~ go eoc ---> Tclass I Tsubclassl l · · · I Tsubclassn ---> name ---> name ---> letter ( letter I digit )* eoc (at most 8 characters)

3. A class T = recordof (subtypeof(Tsup), T1 , ... , Tn), where T1, ... , Tn are elementary data types, leads to the productions:

Tclau ---> ( Tcomp Tel au) I Tcomp Tcomp ---> Tsupclau iTldeJ I· . . ITndef

if Tidef is a scalar type: Tide! ---> (dTi eoc number eoc) I --type= dparam

48

Tidef -->

Tidef -4

char -4

( sTi eoc char eoc) Ti eoc number eoc Ti eoc char eoc

1 character* 1

if Tidef is an array type:

-- type = int, real, double -- type = char, name, sname, input

Tidef -4 ( dTi range narr) I -- type = dparam ( sTi range carr)

Ti rang e n arr -- type = int, real, double Ti range carr -- type = char, name, sname, input

range --> eoc I (blank* "(" irange ")" eoc ) trange-4 (index eoe irange) I (index blank*) index -4 blank* n l : l(n :)!(: n) l(n : n) n -4 number eoe --> blank* , !blank narr -4 number I (blank* "[" ncol "]" eoc)

--> char I (blank*"[" ccol "]" eoc) carr ncol ccol

--> (nrow eor ncol) I (nrow blank*) -4 (crow eor ccol) I (crow blank*)

nrow -4 blank* (number eoe nrow) I number crow --> blank* (char eoe nrow) I char eor --> blank* ; i eol

According to the defined rules, the grammar for the mbs file format is given by:

mbsclau --> (mbscomp mbsclau) lmbscomp eof (=goal production) mbscomp -4 blockcomp jglobaldef lpartdef jinteractdef blockcomp --> inputdef loutputdef lparamdef partdef -4 part eoc part,.1 go eoc part , .t -4 part,etcomp part,et jpart,etcomp part ••tcomp -4 part new jpartcopy lpartlink lpartelem par~new --> new eoc obj ectname classname partclaue• go eoc partcow -4 copy eoc objectname objectname part link parte/em partclaue• partclau partcomp rigidclau rigidcomp bodydef bodyclau bodycomp massdef

-->

-4

-->

-4

-4

-4

-->

-4

-4

-4

-4

link eoc objectname obj ectname obj ectname par tclaue• go eoc partclau !rigidclau lmodalclau (partcomp partclau) lpartcomp framedef

( rigidcomp rigidclau) lrigidcomp partcomp I bodydef body eoc bodyclau go eoc (body comp body clau) I body comp massdef imframedef linertiadeJliframedef (dmass eoc number eoc) I (smass eoc char eoc)