Dynamic Simulation of Multi-Body Systems on Internet Using CORBA, Java and XML

Multibody System Dynamics 10: 177–199, 2003.© 2003 Kluwer Academic Publishers. Printed in the Netherlands.

177

Dynamic Simulation of Multi-Body Systems onInternet Using CORBA, Java and XML

JOSÉ IGNACIO RODRÍGUEZ1, JOSÉ MANUEL JIMÉNEZ1,2, FRANCISCOJAVIER FUNES3 and JAVIER GARCÍA DE JALÓN1STT Engineering and Systems, S.L., Parque Empresarial Zuatzu, Edif. Easo,E-20018 San Sebastián, Spain2Public University of Navarra, Spain3Telefónica de España, S.A., Beatriz de Bobadilla 3, E-28015 Madrid, Spain4Escuela Técnica Sup. de Ingenieros Industriales, Universidad Politécnica de Madrid,José Gutiérrez Abascal 2, E-28006 Madrid, Spain; E-mail: [email protected]

(Received: 5 November 2001; accepted in revised form: 7 March 2003)

Abstract. In this paper a prototype of a computer program for multi-body simulation based onthe use of CORBA, Java and XML is presented. This prototype makes use of a recursive dynamicformalism which outperforms many implementations based on global formulations. The prototypepresented has been implemented using distributed Object Oriented Programming techniques. Thedefinition of the multi-body system is done through a data file defined using XML (eXtendibleMarkup Language). This prototype implements a ‘simulation service’ on a network of computers,following a client-server scheme. This ‘simulation service’ can operate in two different ways: offer-ing a remote simulation on the server, or providing a Java compiled code for local simulation on theclient. The paper describes the practical implementation of such a service. The use of recursive func-tions and OOP permits the implementation of a general-purpose simulation code, which is compact,clear, clean, re-usable and easy to maintain. Once this Java code is compiled, it is stored in less than125 Kbytes (including the numerical integrators). The Java programming language is used in orderto assure compatibility between different platforms. Finally, practical examples which make use ofthis approach are shown.

Key words: multi-body systems, mechanical simulation, distributed computing, Java, CORBA,XML.

1. Introduction

Kinematic and dynamic simulation of multi-body systems (MBS) is an importantpart of MCAE (Mechanical Computer Aided-Engineering). Computer simulationof MBS, such as ground vehicles, satellites, heavy machinery, etc, implies thecomputer solution of complex numerical problems and efficient numerical meth-ods must be implemented in order to obtain the desired solution. In opposition tobatch-oriented applications such as FEM codes, multi-body simulation programspay special attention to interactivity issues and even real-time simulation. For thisreason, the computer environment which is used to run MBS simulation programs

178 J.I. RODRIGUEZ ET AL.

is a matter of paramount relevance. In this context, the main topic of this paper ispresented. This paper introduces a computer program which takes full advantageof the possibilities offered by new computer technologies and specially Internet.This software prototype is based on the use of CORBA objects, Java and XML as asupport for the development of an MBS simulation code which runs on distributedenvironments and even Internet, maintaining a high numerical efficiency as well ashigh flexibility of use.

A detailed description of the dynamic formulations included in this softwareprototype can be found in [1, 2]. This computer code implements the followingdynamic formulations:

• A fully recursive topological formulation for open-chain MBS, based on theArticulated Inertia Method, introduced by Featherstone [3] and modified byBae and Haug [4, 5].

• Two semi-recursive topological formulations for open and/or closed chainMBS are implemented. Closed-chain mechanical systems are analysed fol-lowing a two-step scheme. Closed loops are first opened by removing somekinematic joints or rigid bodies (rods). The resulting open-chain system isanalysed using an open-chain approach. In the second step, the kinematicloop-closure conditions are introduced either by the penalty method [6, 7]or by a second velocity transformation [7, 8].

The software prototype described includes two numerical integration schemes,which make it possible to compute the solution of non-stiff and stiff systemsof differential equations. These numerical integrators are versions of the ode113and ode15s functions, which form part of the MATLAB Ode Suite, developedby Shampine and Reichelt [9]. The ode113 function implements the Adams–Bashforth–Moulton PECE formulae and the ode15s implements the NDF (Nu-merical Differentiation Formulae), for stiff problems. Both numerical integrationfunctions are originally based on the calculation of the derivatives of the state vari-ables. However, in order to adapt to the peculiarities of the numerical integrationof MBS, the ode15s function has been modified in order to work in an implicitmanner, computing the residual of the differential equations and its Jacobian matrixwhen required by the iterative solution of the resulting system of non-linear equa-tions. This implicit form is common to some very well known numerical integrationroutines, such as DASSL [10].

The use of recursive dynamic formulations and object-oriented programmingtechniques makes it possible to re-use object methods and functions, with import-ant savings in the final size of the simulation code. The compressed *.jar file, whichcontains all the executable files *.class, takes less than 125 Kbytes in practicalexamples. This small size makes it possible to transfer these executable files to alocal network or even through the Internet in a matter of seconds, offering newpossibilities for the remote or collaborative use of MBS simulation programs.

DYNAMIC SIMULATION OF MULTI-BODY SYSTEMS ON INTERNET 179

2. New Software Architectures

In the last decade, the architecture of software applications has undergone im-portant changes. The most relevant factors in this evolution are: (a) the maturityreached by low cost personal computers (PCs) as tools for communication andfor scientific and technical calculations; (b) the development of computer networksand client-server applications, and (c) the development of multi-platform standardssuch as Java, XML and CORBA, for the development of cross-platform distributedapplications.

These new possibilities have still not been fully integrated in CAE (ComputedAided Engineering) commercial products. In many practical cases, technical andscientific computer programs are still used in the ‘most traditional’ way, usinginput data files, a batch-oriented execution mode and off-line visualisation of theprogram results.

2.1. THE EVOLUTION OF COMPUTER HARDWARE AND COMPUTER NETWORKS

In the last two decades, mainframes were substituted by mini-computers first,then by networks of workstations and finally, by networks of PCs. In 1993, theintroduction of the first graphic browsers for the World Wide Web generated the‘Internet revolution’. Despite the evident limitations of the bandwidth, these prim-itive browsers marked a significant change in the use of computer networks andcompletely transformed the concept of corporate networking. Nowadays it is pos-sible to perform distributed technical calculations, even running distributed virtualreality applications.

The benefits of the use of these new technologies in multi-body dynamic simu-lation becomes clear. The architecture of the software prototype introduced in thispaper will make it possible to use the Internet in a very efficient way in order toperform remote simulation of a particular mechanical system.

2.2. THE EVOLUTION OF SOFTWARE ARCHITECTURE: CORBA, JAVA AND XML

Software applications architecture has evolved on a parity with the new com-puter and communication infrastructures that support them. Traditionally, technicalsoftware applications were executed in batch mode and only a reduced team of spe-cialised technicians had access to them. Another important drawback was portingthose applications to different computing platforms, which was a difficult and cum-bersome task, sometimes more expensive than the total cost of a new developmentfrom scratch.

This undesirable situation has changed with the introduction of the new client-server architectures. This new approach allows for the development of newsoftware applications based on the concept of ‘components’, which can be ex-ecuted on different computers even though they may be running under differentoperating systems. The World Wide Web is a paradigmatic example of this type


of applications. The success of WWW is based on its simple and intuitive userinterface, which is common to all the platforms and independent of the operatingsystem. Internet browsers have become universal clients that make it possible to usecustom software applications from anywhere with a minimum effort of softwareinstallation and maintenance. However, in the field of CAE and especially in multi-body dynamic simulation, there is a lack of technical applications developed forthese new computing environments.

Distributed computing was introduced in the early seventies with the devel-opment of the first minicomputers, the computer networks and the first objectoriented programming languages. Distributed objects make it possible to redesignthe client-server applications by the use of software ‘components’, which are akind of autonomous software elements that can communicate with each other.CORBA is a technology for integration of software components that is independentof the programming language, the computing platform, the operating system andeven of the particular implementation of CORBA. Clients only have to invoke amethod from a server object without any concern for the details of the objectimplementation or hosting. The method is invoked from the client using its ownprogramming language and the response is obtained from the server regardless ofthe programming language used in its implementation.

In May 1995, Sun Microsystems introduced the Java programming language.Although Java was originally oriented to the development of small applications tobe run inside consumer electronics and Internet browsers, it has been successfullyextended to the development of large server applications. Java syntax is similar tothat of C and C++, simplifying some of the most intricate issues of those languages,such as pointer arithmetic, multiple inheritance, memory management, etc. Eckel[11] and Campione et al. [12, 13] are excellent references for Java that can also befound in electronic form and freely downloaded from Internet. Orfali and Harkey[14] compare the combination of Java and CORBA with other approaches for thedevelopment of distributed applications. One of the main drawbacks of the earlierversions of Java was the low efficiency of the applications in terms of computa-tional times. This drawback has been overcome with the help of the new compilertechnologies. With these new compilers Java applications give execution times only80% greater than those obtained with C++ applications, which may be acceptableconsidering the other advantages derived from the use of Java.

Since the beginning of 1999, XML (eXtensible Markup Language) has becomeone of the most popular means for portable and non-proprietary definition of data,supported by an increasing number of software vendors and professional associ-ations. In the subject of data XML plays a role similar to that of Java in the subjectof applications. Marchal [15] provides a detailed description of XML including alarge collection of practical examples.

XML is a ‘meta-language’, that is, a language used for the definition of otherlanguages by establishing their syntactical rules, the structure of the file or doc-ument that contains the data, etc. The XML standard allows programmers and


developers to create their own description language for their data files, definingnew tags similar to those used in HTML files and documents. XML documentscan be ‘valid’ and ‘well-defined’. A ‘valid’ document must obey the general syn-tactical specifications given by XML for tag-based documents. A ‘well-defined’document must also satisfy the syntax and structure of a particular application,which is defined in a Document Type Definition file (DTD) or in an XML Schema,which define the tags allowed for a particular application, including the hierarchy,the values allowed for each tag and parameter, etc. In this way, a new language caneasily be created for the definition of any physical system such as an MBS. Freeprograms for parsing XML applications can be easily found on the Internet.

As stated by Otter et al. [16] one of the main difficulties in the comparisonof different multi-body simulation codes and formalisms is the lack of a standarddata file for MBS definition. For this reason these authors proposed a neutral datafile based on object oriented programming concepts. Currently, XML has becomethe most adequate language for the definition of such standard data file. In thispaper, a prototype of an MBS definition language based on XML has been in-troduced. This language is called MechML (Mechanism Modeling Language; seehttp://mat21.etsii.upm.es/mbs/MechML/ for additional information). Ap-pendix A presents a MechML practical example of an MBS defined using thislanguage.

3. MechService Software Architecture

3.1. INTRODUCTION

In this paper, the prototype of a ‘multi-body simulation server’ is introduced.This server has several ‘components’, that provide a wide range of services formulti-body simulation. One of the most relevant services is the generation andexportation of Java compiled code for the simulation of a particular mechanism,either in the server or the client machine, in a totally automatic way that requiresno intervention from the analyst. This multi-body simulation server is a part ofthe application called MechService, which is able to offer services for local orremote simulation of MBS through the Internet. This architecture makes use of theMechML language for the definition of the MBS as well as the type of simulationto be performed.

The first general-purpose computer programs for muti-body simulation weredeveloped in the late sixties and the early seventies. These programs were batch-oriented codes. During the 7th World Congress of Mechanism and MachinesTheory held in Sevilla (Spain) in 1987, García de Jalón et al. presented a prelimin-ary version of COMPAMM (COMPuter Analysis of Machines and Mechanisms),a pioneer general-purpose computer code that included 3D realistic graphics. Thiscode was capable of performing interactive kinematic simulations of complexMBS, allowing the analyst to interactively modify the values of the degrees of


freedom. Almost real-time dynamic simulations were also possible for simplemulti-body models.

Recent research reported in the specialised bibliography explores new softwarearchitectures for multi-body simulation. In 1997 Jiménez et al. [17] presented amodification of COMPAMM software that allowed the parametric simulation of agiven multi-body system in a local network of non-dedicated heterogeneous com-puters. This code was based on the use of the message-passing paradigm and wasimplemented using the PVM library [18].

More recently, Tseng and Hulbert [19] also explored the possibilities of dis-tributed dynamic simulation of MBS. These authors presented an algorithm calledGluing Algorithm, which performs dynamic simulation by synchronising differentprocesses running on one or several processors. This algorithm is based on thecoordinate-split method, presented by Yen and Petzold [20]. The iterative Newtonprocedure is performed by solving the open-chain problem in parallel using differ-ent processes. Closed-chain conditions are imposed when the computations of thedifferent mechanical subsystems are synchronised. Kim [21] developed a methodfor vehicle dynamics simulation based on the ‘subsystem’ concept. Subsystemsare linked to a common body (usually the vehicle chassis) but must have no con-nection between each other. Kübler and Schiehlen [22] introduced a methodologyfor multi-body dynamic simulation which obtains the set of differential equationsby using a simplified ‘block diagram’ of the mechanical system. This approachintroduces a new iterative procedure to couple the different blocks or subsystems.

In spite of these works, almost all the commercially available computer codesfor MBS simulation maintain their batch-oriented original architecture. Advanced3D graphic postprocessors have been included in the simulation packages, but theyare simply used to visualise the results obtained from the computation. Distributedcomputation concepts have not yet been implemented on those applications.

In the decade of the 90s, much time and effort was devoted to the integrationof software tools which allow the simulation of systems from different engineeringfields: CAD programs, MBS simulation packages, hydraulic simulators, programsfor the analysis of electronic and control systems, etc. This integration can beperformed at different levels: through data files, using co-simulation techniques,following an integrated simulation approach and, finally, using software compon-ents (‘objects’) from the different engineering fields. The last approach would seemto be the most promising one, since it allows for the building of heterogeneousapplications that integrate software components specialised in the simulation ofthe different physical subsystems.

According to different authors [23–25], future CAE systems will be composedof small and compact software components, developed by different software pro-viders, which will interact with each other without the need for intervention fromthe final user. Once a given CAE application needs a given type of computation,a CORBA service will indicate the products available on Internet. The client will


select one of those products, which will be integrated in the application locally orin a remote mode, in order to perform the requested computation.

In accordance with these ideas, a CAE application would execute componentsremotely to perform a kinematic or dynamic simulation, or would even importcompiled code in order to perform the simulation locally. This would be the typicaluse of the software architecture described in the next section.

3.2. DESCRIPTION OF MECHSERVICE ARCHITECTURE

The component architecture of the MechService, introduced in this paper, wouldallow an easy integration of an MBS simulation program in a CAE environment.MechService offers MBS simulation services on a local network or through theInternet. This service is offered in two different ways:

• Remote simulation on the server. In this approach, an MBS model is definedon the client machine by means of a MechML file, which is sent to theserver for remote simulation. The client machine will receive results fromthe simulation either during the simulation or at the end of the process.

• Local simulation on the client. As in the previous option, an MBS model isdefined on the client machine by using a MechML file. The server generatesa Java code for this particular model, compiles it and sends the code to theclient, who integrates this code with the MBS analysis program in order toperform the simulation. If no MBS analysis program is available on the clientmachine, the server also sends the general purpose simulation code to theclient machine.

Figure 1 depicts the architecture of MechService. The arrows indicate whichmodule performs the calls to functions or methods. The MechServer object per-forms all the tasks related to control and synchronisation. The MechClient objectsare the client applications that will request MBS dynamic analysis services. TheMechSim object performs the dynamic simulations. The MechService object cancreate as many instances of the MechSim objects as required by the clients. Mech-Client objects are able to call methods from the components MechServer andMechSim. Similarly, MechClient objects act as servers for MechSim objects in sometasks, for instance in the transmission of messages coming from errors that mayappear during the simulation of the MBS.

The way this architecture works is described in the following points:

1. MechServer object starts and waits until an MBS simulation service is reques-ted. MechClient objects are available on those systems that may need an MBSsimulation.


Figure 1. Component structure of MechService.

2. One or more MechClient objects connect to MechServer in order to request anMBS simulation. A MechML file containing the definition of the MBS is sentfrom the client to the server.

3. MechServer object creates an instance of a MechSim object and sends backto the requesting MechClient object a reference to the new MechSim object.The new MechSim object can be created and run on the same machine whereMechServer is running, on the machine where the MechClient object is runningor on any other machine in the network that allows a MechSim object to be run.In addition, MechServer may have some MechSim objects already created andready to be used as soon as a request for a MechClient object arrives.

4. MechClient sends to the new MechSim object a MechML file containing thedescription of the MBS to be simulated.

5. At this stage, MechClient is able to perform the simulation of the MBS modelusing some methods provided by the MechSim object. The MechClient objectcan also request the compiled code corresponding to the MBS defined in theMechML data file. The compiled code is executed locally by the MechClientobject in order to perform the simulation. The MechClient object can also re-quest the general purpose methods needed to perform the dynamic simulation,if they are not locally available.

The last point in this description is a key point of the proposed architecture. Fig-ure 2 shows the interaction between the client and the MechSim components, whena remote execution on a MechSim component is requested. Figure 3 depicts theinteraction between the different objects when the MechClient object is going toperform the dynamic simulation locally. The Java objects are transferred throughthe net by using JAR (Java ARchive) files.


(1) The client requests to MECHSIM a remote simulation and sends the MechML file.(2) MECHSIM creates an IMECHSIMREMOTE object.(3) A reference to new created IMECHSIMREMOTE object is returned.(4) The client uses the methods of this reference to perform the remote simulation.

Figure 2. Client-MechSim interaction; remote simulation in MechSim.

(1) The client requests a local simulation and sends the MechML file.(2) MECHSIM creates a JAR file with the model compiled code.(3) MECHSIM sends the generated JAR file.(4) The client decompresses the JAR file.(5) The client executes the simulation with the received code for the model.

Figure 3. Client-MechSim interaction; local simulation in the client side.

The main objective of MechServer objects is to control the status of the applic-ation, managing the different MechSim objects present on the network. In order toperform this task, it incorporates an interface that makes it possible the control thestatus of the different components, from a client-administrator (MechAdmin).

Several instances of MechServer can be running simultaneously in a network.Connection policies will define where and how a client must be connected. In turn,a single MechServer component may simultaneously attend the requests comingfrom different clients: CAD programs, local clients, Web clients, etc. Finally, itmust be pointed out that a MechClient object is able to handle several MechSim


objects simultaneously. A MechClient object may receive references to severalsimulations or MechSim objects running on different computers.

The way the simulation results are obtained by a MechClient object may varydepending on the type of simulation performed by the object. In a simulation per-formed locally, the interface methods give access to all the variables and methodsof the compiled code received by the client and results are then directly obtainedfrom the simulation. In a remote simulation, there are two possibilities dependingon whether the client requests results at each integration step or only asks for outputdata when the simulation is done.

As mentioned before, the MechClient object optionally implements an interface(called IMechClient) that can be called from MechSim objects in order to check thestatus of the simulation and, eventually, get the error messages generated by thesimulation process.

The MechService architecture described in this section opens up new and veryinteresting possibilities for MBS simulation. The following points summarise someof these possibilities:

1. It is possible to run heavy or very time-consuming simulations from any clientcomputer, even if it is a low performance machine. The client machine canrequest simulation services from any server machine available on the Internet,thus allowing for the execution of complex simulations in a relatively shortelapsed time.

2. It is possible to simplify the control of versions and licenses of the simulationprograms. In a big corporation, licenses and new versions of the simulationprograms must only be updated on the server machines. Client machines willalways request simulation services from the servers, having access to the latestversions of the simulation packages. This approach will also allow for theimplementation of a remote license program or a pay-per-use service on theInternet.

3. Using this architecture, interaction between different simulation codes is easierand cleaner. An important field of application is the integration between CADand MBS simulation programs, in order to analyse the large displacementsthat the different parts of the MBS undergo during normal operation, collisiondetection, etc.

4. Optimum design of MBS is another activity that can be easily undertaken usingthis software architecture, which allows for the parallel execution of differentsimulations on the different processors available on the network.

In this section, the MechService architecture has been presented. Its aim is to offera multi-body dynamic simulation service on a LAN or on the Internet.


4. Practical Examples and Results

4.1. DESCRIPTION OF THE COMPUTER ENVIRONMENT

The tests have been performed on two local PCs Intel Pentium� II, 400 MHz and128 Mbytes of RAM, running Windows NT Workstation 4.0, and a remote PCIntel Pentium� III, 800 MHz and 256 Mbytes of RAM, running Windows NT 4.0Server. These are out-of-date systems that are affordable to any private person orinstitution.

The Local Area Network (LAN) used in the tests was an Ethernet of 10 Mega-bits per second. The local computers were located in the School of IndustrialEngineering of San Sebastián (University of Navarra), whereas the remote com-puter was in the School of Industrial Engineering of the Polytechnic University ofMadrid. The Wide Area Network used has a maximum bandwidth of 2 Megabitsper second. This network is shared by many universities in Spain so it is verydependent on the timetable.

The results shown in this section have been obtained with a program written inJava. The Java Development Kit version 1.2.2 by SUN has been used. This versionincludes a JIT (Just In Time compiler). The JacORB CORBA implementation [26]has been selected. This freeware implementation is written completely in Java.

4.2. DESCRIPTION OF THE PRACTICAL EXAMPLES

In the following sections the examples used to validate the proposed architectureare described. Two examples of open-chain mechanism ‘a three-dimensional five-bar pendulum and the model of the human body of a driver’ and one closed-chainmechanism ‘a five-link rear suspension’ have been chosen.

4.3. OPEN-CHAIN EXAMPLES

The five-bar pendulum shown in Figure 4 has five consecutive revolute joints andfive degrees of freedom. The length of all the links is L = 1 m and they have auniformly distributed mass M = 1 kg. The pendulum, initially at rest, is left freeand evolves under the effect of gravity.

The human body shown in Figure 5 has 39 bodies and 45 degrees of freedom.For convenience, the model used for computation uses only revolute joints. Uni-versal joints were represented as two perpendicular revolute joints, and sphericaljoints as three mutually perpendicular revolute joints. A prismatic joint has beenadded between the hips and the seat, and a revolute joint between the seat and theground. Therefore, the global system has 41 bodies, 40 revolute joints, 1 prismaticjoint and 41 degrees of freedom. The interaction with the environment (steeringwheel, safety belt and seat) has been achieved by introducing position and velocitydependent forces.


Figure 4. Five-bar pendulum.

Figure 5. Driver model.

The driver is assumed to be seated in a natural driving position. To model thebehavior of the driver’s muscles, torsion springs and dampers have been introducedat the joints. Before the frontal collision takes place, the driver is traveling at aconstant speed of 5 m/s. The system described has been simulated in two differ-ent conditions. First, damping in the joints has not been introduced, which leadsto a non-stiff system. In the second case, torsion damping (1% of its rigidity totorsion) has been introduced in the joints. This damping, which is considered to bereasonable and not very high, introduces enough stiffness in the system equationsto render explicit integrators useless, so the simulation is considered stiff. Thesimulation time is 250 milliseconds.

4.3.1. Closed-Chain Example

The five-link suspension shown in Figure 6 is a rear multi-link suspension used bysome European cars. It has eight degrees of freedom but five can be consideredas secondary degrees of freedom (those corresponding to the rotation of the rods


Figure 6. Five-link rear suspension.

around its own axis), so it is possible to consider only three degrees of freedom.To convert the model into an open-chain mechanism it is convenient to remove thefive rods, adding the corresponding distance constraints plus the inertia and staticforces effects over the adjacent bodies. The simulation consists of studying theeffect of a staircase. The simulation time is 2 seconds.

4.4. RESULTS OF THE DISTRIBUTED EXECUTIONS

In this section, some numerical results related to the implementation and executionof the architecture MechService described previously are shown.

The cost of executing a function, using CORBA, in a local or remote way (in thePC, across the LAN or on the Internet) is a very important factor for the practicalusability of MechService. The times vary substantially with the type of network, theload and the precise state of their different systems (computers, routers, firewalls,etc.).

Some experiments carried out by the authors of this paper allow to concludethat the simple execution of a function (ping) with CORBA costs approximatelythe same in one’s own PC as in another PC of the local network (order of the mil-lisecond). If the execution is made through the Internet, the times are between 20and 50 times longer. When the execution of the function implies data transmission,the local network is 5 times slower than the PC, whereas the Internet is between 8and 15 times slower than the local network.

So, the remote execution of simulations through the Internet is mainly justifiedwhen it is carried out on a much more powerful computer and making almost allthe transmission of information once the execution is completed. Nevertheless, theexecution of distributed objects in a good local network is already totally justified.It is important to remember that both the local network and the Internet used forthis work are slow connections according to the current standards.


Figure 7. Qualitative scheme of the time distribution in the MechServer application. Execu-tion in the client side.

Figure 8. Qualitative scheme of the time distribution in the MechServer application. Execu-tion in the server side.

As explained before, the MechService architecture offers the options of bothlocal and remote simulations. The file sending, the compiling of the code generatedspecifically for a model, the compressing/decompressing of the code to be sent, aretasks that are not implemented in traditional applications. Therefore, it is importantto have an idea of the cost in terms of elapsed time that they represent.

The mechanisms chosen for this study correspond to different-sized files (theMechML data files and the corresponding Java classes, compiled according to themodel information). Two of the models have user-defined forces, implemented bymeans of specific methods programmed in Java. This is why the compiled codesent to the client has several files.

Figures 7 and 8 represent the tasks performed by the MechServer application.Note that the initial part is exactly the same in both cases, irrespective of whetherthe simulation is executed locally or remotely.


Table I. Time measures for different tasks in the MechServer application.

Measure Pendulum FPS Driver

Size of the XML file 4.3 Kbytes 5.6 Kbytes 33.5 Kbytes

Size of the compiled model JAR file 2.2 Kbytes 7.1 Kbytes 11.8 Kbytes

Time t1c 0.10 0.11 0.32

Time t1s 0.08 0.09 0.23

Time t2c 0.22 0.69 1.13

Time t2s 0.11 0.32 0.55

Compilation time tcc 0.21 0.25 0.31

Total time for remote execution set-up tR 0.38 0.51 0.70

Total time for local execution set-up tL 0.62 1.15 1.82

The elapsed times shown in Figures 7 and 8 and in Table I correspond to thetasks described below (time in seconds):

• Time t1c: Time corresponding to reading of the MechML file in the client,sending of this file to the server, processing it in the server, generating theJava class (without compiling) for the model defined in the MechML file, andnotifying the end of the process to the client.

• Time t1s: Time in the server, corresponding to processing of the MechML fileand generating the Java class (without compiling). The difference between t1cand t1s corresponds to the time in which the MechML file is read in the client,the sending of this file in the local network and the notification from the serverto the client.

• Time t2c: elapsed time between the moment the client receives the notificationof the generation in the server of the Java code corresponding to the MechMLfile, and the moment the client receives the compiled code of this model. Thistime does not consider the time tcc, spent by the compilation in the server, butincludes the creation of the JAR file in the server, its delivery to the client, anddecompression in the client.

• Compiling time tcc: Time spent by the server to compile the Java code of thereceived model. This compilation has been performed using the IBM Jikesapplication, which considerably speeds up the compilation of Java classes.

• Time t2s: Time spent by the server to create the JAR file from the result of thecompilation.

• Total time used in the set-up of the remote execution tR: this time representsapproximately the total time needed, starting from a MechML file, by theclient to have a remote component ready to perform the simulation. This timeincludes the set-up of the MechSim component, t1c, the compilation time tcc,and the IMechSimRemote component generation.


• Total time used in the set-up of the local execution, tL: this time correspondapproximately to the total time needed by a client to obtain the compiled codeof a particular mechanism. This received code is ready to be executed locallyby the client. The time includes the set-up of the MechSim component, andt1c, tcc and t2c times.

The times shown in Table I have been obtained by executing the previouslydescribed examples in a local network (10 Mbits/s Ethernet).

The code that performs the dynamic simulation is the same for all the examples.Thus, the time needed to unload it does not depend on the model considered. Thedownloading of this general-purpose code only occurs the first time the clientuses it, or when this code has been upgraded in the server, simply to add newimprovements or to eliminate bugs. This code has been implemented totally in Java,and includes methods based on the recursive calculus of the motion differentialequations residue, with and without the analytical approximation of its Jacobianmatrix (RR, RR-JF), a semi-recursive method (DSR) to compute the derivative ofthe state vector, a totally-recursive method for open-loop systems (DTR); see [2]for a detailed description of these algorithms. The integration algorithms ode15s,ode15sR and DE are also included. The total compressed size of this code is only125 Kbytes, and the time needed for downloading and unpacking this code, accord-ing to the tests performed, ranges from 6 seconds in the local network to 9 secondsin the Internet. The XML parser is in the server and is never sent to the client.

According to the results shown in Table I and, regardless of their dependencyon the state of the local network, some concluding remarks can be made:

1. The time needed to enable a component to execute a simulation, starting froma MechML file, is under a second.

2. Similarly, the time needed to obtain the compiled code of a specific mechanismis slightly over a second, but is about the same order of magnitude.

The previous remarks show that the MechService architecture can be used perfectlyby other applications, such as CAD programs.

5. Comparison with Other Simulation Environments

The MechService architecture would not be totally presented without the compar-ison of its simulation times and those corresponding to other implementations orwell proved efficient commercial programs. The Java programs implemented inthis work have been tested against others implemented in C++. The structure ofboth programs is exactly the same even in all aspects related to the OOP approx-imation (abstraction, inheritance, polymorphism, etc.). Both implementations havebeen executed in the same way: direct execution, in a local computer, without localnetwork and CORBA. Therefore, the execution times depend only on the language


Table II. Comparison between the SIMPACK program and C++ and Javaused in this work. Total time in seconds.

Program Integration method Pendulum Driver DriverC = 0 C = K/100

SIMPACK LSODE (Adams) 0.15 6.95 39.03

SODASRT 0.29 8.40 0.79

C++ DTR-DE 0.08 2.35 8.02

RR-JF-ode15sR 0.10 3.32 0.25

Java DTR-DE 0.14 3.94 13.06

RR-JF-ode15sR 0.24 7.98 0.53

and the compiler used. The C++ programs have been created using the MicrosoftDeveloper Studio 97 tool (Visual C++ 5.0), whereas the Java programs have beenexecuted using the Sun’s JDK 1.2.2 and the Symantec JIT compiler.

Furthermore, the Java and C++ implementations have been compared to thecommercial application SIMPACK 8.0 [27–29], which is probably the most effi-cient on the market. Table II shows the results obtained. The PC used in the tests isequipped with a 500 MHz Intel Pentium� III processor, 128 Mbytes of RAM andthe Windows NT Workstation 4.0 operating system.

The results in Table II show that times corresponding to the Java implementationare approximately twice the times corresponding to that in C++. In both cases theresulting times are lower than those obtained with SIMPACK. The name DTR-DE indicates a totally recursive dynamic formulation, based on the ArticulatedInertia method, using an Adams–Bashforth–Moulton type integrator [9]. The nameRR-JF-ode15sR represents a semi-recursive formulation based on the recursiveevaluation of the residual and on an analytical approximation of the Jacobianmatrix, along with a modified Matlab’s ode15s integrator [9].

The results in Table II show that the use of Java in technical and scientificapplications is already a valid and competitive option. The major drawback inthe simulation time versus C++ is compensated by the benefits of a platform-independent code and the local execution of an imported code from a remoteserver.

6. Final Conclusions and Remarks

With respect to the possibilities that the new tools and computer architectures offerto the mechanism simulation, based on the prototypes and the experience gained inthis work, the following observations can be made:

1. The Object Oriented Languages, such as Java or C++, present many advant-ages not on efficiency, but on readability and maintainability for instance incomparison to other algorithmic languages such as FORTRAN. Their majordrawback is the lower numeric efficiency. Some tests performed within thiswork indicate that there is a performance loss when using C++ instead ofFORTRAN (regardless of the use of compilers and programming techniquesespecially oriented to numerical calculus). Execution times when using C++codes may be up to a 25% longer than when using FORTRAN codes. In turn,Java codes may be 50 to 100% slower than C++ codes.

2. Despite this drawback in the numeric efficiency, Java is competitive in com-parison to C++ and FORTRAN, because of its multi-platform and codeexportation capabilities.

3. The MechService architecture shows great possibilities in remote mechanismsimulation services, together with easy maintenance, control of versions andlicenses, etc.

4. The size of the dynamic simulation code (including all the cited topologicalmethods and the numerical integrators) is, after compressing, only 125 Kbytes.That is because of the use of recursive functions and the program modulararchitecture, which allow a considerable re-use of methods. The size of thiscode allows for its use in the Internet and its integration with other applications.

5. Java has the advantage of being able to send compiled code from one com-puter to another without having to re-compile this code. This process can beperformed in a totally transparent form for the user and in a very reduced time(a few seconds).

6. A draft of a new data file format, specific for mechanisms, has been defined:The MechML format. This format is easy to understand and can easily beparsed by any application.

7. Local networks are a very suitable architecture for using the presented concept.The Internet may also be quite valid, at least when the net is not over-loaded.The spread of wide-band and the arrival of new Internet2 will improve thesituation.

Appendix A

The data file corresponding to the Five Point Suspension, described in Sec-tion 4.2.2, is shown below. It has been implemented in the MechML language.As can be seen, the format can be easily be understood and used, and resemblesconsiderably to HTML, broadly used in Internet.

<?xml version="1.0"?><!DOCTYPE MechML SYSTEM "MechML.dtd"><!--

FPS : Five Point Suspension


Dynamic simulation of a five point suspensionDegrees of freedom:

- the displacement of the car along the X axis- the vertical displacement of the centre of the wheel- the spin of the wheel

Next files represent the user-defined forces:- examples.fivepointsuspension.FpsFBody- examples.fivepointsuspension.FpsSpringDamper

--><MechML>

<MBSsimulation><dynamic>

<timeSet tini="0" tend="2" tstep="0.01"/><integrator name="DE" relTol="1e-05" absTol="1e-05"/>

</dynamic></MBSsimulation><MBSmodel name="FivePointSuspension" massUnits="kg"

lengthUnits="m"><Bodies>

<body name="Ground" graphSrc="Base.wrl"><point name="pGround" x="0.0" y="0.0" z="0.0"/><point name="pGround2" x="+0.064" y="-0.413"

z="-0.327"/><vector name="vGround" vx="1.0" vy="0.0" vz="0.0"/><vector name="uFinal" vx="0.0" vy="1.0" vz="0.0"/>

</body><body name="Frame" graphSrc="Frame.wrl">

<point name="p1" x="0.0" y="0.0" z="0.0"/><point name="pc2" x="-.064+0.064" y="0.413-0.413"

z="0.327-0.327"/><point name="pc22" x="-0.303+0.064" y="0.432-0.413"

z="0.295-0.327"/><point name="pc32" x="-0.093+0.064" y="0.366-0.413"

z="0.004-0.327"/><point name="pc42" x="-0.236+0.064" y="0.388-0.413"

z="-0.109-0.327"/><point name="pc52" x="0.2115+0.064" y="0.3845-0.413"

z="-0.10-0.327"/><vector name="u1" vx="1.0" vy="0.0" vz="0.0"/><cog x="-.0001+0.0969" y="0.0003-0.3967"

z="0.0002-0.0818"/><mass value="10.0"/><inertiaTensor Ixx="0.0" Iyy="0.0" Izz="0.0"/>


</body><body name="Carrier" graphSrc="Carrier.wrl">

<point name="p1" x="0.0" y="0.0" z="0.0"/><point name="p2" x="0.1030" y="0.3050" z="-0.0870"/><point name="pc1" x="-0.0640+0.103" y="0.6360-0.463"

z="0.3450-0.0870"/><point name="pc21" x="-0.1170+0.103" y="0.6360-0.463"

z="0.338-0.0870"/><point name="pc31" x="-0.1880+0.103" y="0.6470-0.463"

z="-0.023-0.0870"/><point name="pc41" x="-0.005+0.103" y="0.737-0.463"

z="-0.130-0.0870"/><point name="pc51" x="0.0025+0.103" y="0.7370-0.463"

z="-0.134-0.0870"/><vector name="u2" vx="0.0" vy="0.820/0.820061"

vz="0.01/0.820061"/><cog x="0.0" y="0.0" z="0.0"/><mass value="15.0"/><inertiaTensor Ixx="0.30" Iyy="0.20" Izz="0.20"

Ixy="-0.010" Ixz="-0.0150" Iyz="-0.050"/></body><body name="Wheel" graphSrc="Wheel.wrl">

<point name="p1" x="0.0" y="0.0" z="0.0"/><vector name="u1" vx="0.0" vy="0.820/0.820061"

vz="0.010/0.820061"/><cog x="0.0" y="0.0" z="0.0"/><mass value="12.0"/><inertiaTensor Ixx="0.7400" Iyy="1.459892943"

Izz=".740107067" Ixy="0.0" Ixz="0.0"Iyz="0.877918562E-2"/>

</body></Bodies><Joints>

<joint name="j1" type="P"><body1 name="Ground" point="pGround" vector="vGround"/><body2 name="Frame" point="p1" vector="u1"/>

</joint><joint name="j2" type="F">

<body1 name="Ground" point="pGround2"/><body2 name="Carrier" point="p1"/>

</joint><joint name="j3" type="R">

<body1 name="Carrier" point="p2" vector="u2"/>


<point name="pGround" x="-0.064" y="0.413"z="0.327"/>

<vector name="vGround" vx="1.0" vy="0.0" vz="0.0"/></inipos>

</root><relCoorVals>

<jointVal name="j1" posVals="0.0" velVals="30.0"/><jointVal name="j2" posVals="1.0;0.0;0.0;0.0;-0.1030;

0.4630;0.0870" velVals="0.0;0.0;0.0;30.0;0.0;0.0"/><jointVal name="j3" posVals="0.0" velVals="107.9217"/>

</relCoorVals></topology>

</MBSmodel></MechML>

Remark: The file shown in this Appendix does not pretend to be a final spe-cification of the way of representing mechanism by means of XML, but is onlya demonstration of how easy it is to describe mechanisms using new file datalanguages based on XML.

References

1. Rodríguez, I., ‘Análisis eficiente de mecanismos 3D con métodos topológicos y tecnologíade componentes en internet’, Tesis Doctoral, Escuela Superior de Ingenieros Industriales,Universidad de Navarra, San Sebastián, Spain, 2000.

2. Rodríguez, J.I., Jiménez, J.M., Funes, F.J. and García de Jalón, J., ‘Recursive and residualalgorithms for the efficient numerical integration of multi-body systems’, Multibody SystemDynamics, 2002, submitted.

3. Featherstone, R., Robot Dynamics Algorithms, Kluwer Academic Publishers, Dordrecht, 1987.4. Bae, D.-S. and Haug, E.J., ‘A recursive formulation for constrained mechanical system

dynamics. Part I: Open-loop systems’, Mechanics of Structures and Machines 15, 1987,359–382.

5. Bae, D.-S. and Haug, E.J., ‘A recursive formulation for constrained mechanical system dy-namics. Part II: Closed-loop systems’, Mechanics of Structures and Machines 15, 1987,481–506.

6. Bayo, E., García de Jalón, J. and Serna, M.A., ‘A modified Lagrangian formulation for the dy-namic analysis of constrained mechanical systems’, Computer Methods and Applied Mechanicsand Engineering 71, 1988, 183–195.

7. García de Jalón, J. and Bayo, E., Kinematic and Dynamic Simulation of Multibody Systems.The Real-Time Challenge, Springer-Verlag, Berlin, 1994.

8. Jiménez, J.M., ‘Formulaciones cinemáticas y dinámicas para la simulación en tiempo realde sistemas de sólidos rígidos’, Tesis Doctoral, Escuela Superior de Ingenieros Industriales,Universidad de Navarra„ San Sebastián, Spain, 1993.

9. Shampine, L.F. and Reichelt, M.W., ‘The Matlab ODE suite’, SIAM Journal on ScientificComputing 18, 1997, 1–22.

10. Petzold, L.R., ‘A description of DASSL: A differential/algebraic system solver’, IMACSTransactions on Scientific Computation 1, 1982, 65–68.

11. Eckel, B., Thinking in Java, 2nd edition, Prentice Hall, Englewood Cliffs, NJ, 2000.


12. Campione, M., Walrath, K. and Huml, A., Java Tutorial: Short Course on the Basics (The JavaSeries), 3rd edition, Addison-Wesley, Reading, MA, 2000.

13. Campione, M., Walrath, K. and Huml, A., The Java Tutorial Continued: The Rest of the JDK,Addison-Wesley, Reading, MA, 1998.

14. Orfali, R. and Harkey, D., Client/Server Programming with JavaTM and CORBA, 2nd edition,John Wiley & Sons, New York, 1998.

15. Marchal, B., XML by Example, 2nd edition, Que, Indianapolis, IN, 2001.16. Otter, M., Hocke, M., Daberkow, A. and Leister, G., ‘An object-oriented data model for

multibody systems’, in Advanced Multibody Dynamics, W. Schiehlen (ed.), Kluwer AcademicPublishers, Dordrecht, 1993, 19–48.

17. Jiménez, J.M., Matey, L., García, J., Avello, A., Baldini, S., Giraud, L. and Hamel, L., ‘On theuse of high performance computing multi-body analysis for two-wheeler suspension design’,in Multi-Body Dynamics: Monitoring and Simulation Techniques, H. Rahnejat and R. Whalley(eds.), Mechanical Engineering Publications, London, 1997.

18. Beguelin, A., Dongarra, J., Geist, A., Jiang, W., Manchek, R. and Sunderam, V., ‘PVM 3user’s guide and reference manual’, Technical Report ORNL/TM-12187, Oak Ridge NationalLaboratory, Tennessee 37831, 1994.

19. Tseng, F. and Hulbert, M., ‘Network-distributed multibody dynamics simulation – Glu-ing algorithm’, in Advances in Computational Multibody Dynamics, J.A.C. Ambrosio andW.O. Schiehlen (eds.), Instituto Superior Tecnico, Lisbon, Portugal, September 20–23, 1999,521–540.

20. Yen, J. and Petzold. L.R., ‘Convergence of the iterative methods forcoordinate-splitting formulation in multibody dynamics’, Report convg.ps,http://www.engineering.ucsb.edu/∼cse/publica.html, 1995.

21. Kim, S.S., ‘A subsystem synthesis method for an efficient vehicle multibody dynamics’, inAdvances in Computational Multibody Dynamics, J.A.C. Ambrosio and W.O. Schiehlen (eds.),Instituto Superior Tecnico, Lisbon, Portugal, September 20–23, 1999, 379–396.

22. Kübler, R. and Schiehlen, W.O., ‘Virtual assembly of multibody systems’, in Advances inComputational Multibody Dynamics, J.A.C. Ambrosio and W.O. Schiehlen (eds.), InstitutoSuperior Tecnico, Lisbon, Portugal, September 20–23, 1999, 499–519.

23. Strelich, T., ‘Next wave software technologies and their impacts on modeling andsimulation’, in The 11th International Training & Education Conference, ITEC 2000,http://www.itec.co.uk/, 11–13 April 2000, The Hague, The Netherlands, 2000.

24. Toshiki, M. and Cutkosky, M.R., ‘Agent-based collaborative design of pars in assembly’, inProceedings of ASME Design Engineering Technical Conferences, Vol. DETC98/CIE-5697,ASME, New York, 1998.

25. Wang, F.F. and Wright, P.K., ‘Web-based CAD tools for a networked manufacturing service’,in Proceedings of ASME Design Engineering Technical Conferences, Vol. DETC98/CIE-5517,ASME, New York, 1998.

26. Brose, G., ‘JacORB performance compared’, http://www.inf.fu-berlin.de/∼brose/jacorb/, 2000.

27. Rulka, W. ‘SIMPACK, a computer program for simulations of large motion multibody sys-tems’, in Multibody System Handbook, W. Schiehlen (ed.), VDI-Verlag, Düsseldorf, Germany,1993, 256–284.

28. . Rulka, W., ‘Effiziente Simulation der Dynamik mechatronischer Systeme für industrielleAnwendungen’, Dissertation, TU Wien, Austria, 1998.

29. Schwertassek, R. and Rulka, W., ‘Aspects of efficient and reliable multibody system simula-tion’, in Real-Time Integration Methods for Mechanical System Simulation, E.J. Haug and R.C.Deyo (eds.), Springer-Verlag, Berlin, 1991, 55–96.

Dynamic Simulation of Multi-Body Systems on Internet Using CORBA, Java and XML

Documents

Transcript of Dynamic Simulation of Multi-Body Systems on Internet Using CORBA, Java and XML