HAL Id: hal-01723827
https://hal-univ-tln.archives-ouvertes.fr/hal-01723827
Submitted on 18 Feb 2020
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
Distributed under a Creative Commons Attribution| 4.0 International License
A contribution for virtual prototyping of mechatronic
systems based on real-time distributed high level
architecture
Hassen Hadj-Amor, Thierry Soriano
To cite this version:
Hassen Hadj-Amor, Thierry Soriano. A contribution for virtual prototyping of mechatronic systems
based on real-time distributed high level architecture. Journal of Computing and Information Science
in Engineering, American Society of Mechanical Engineers, 2011, 12 (1), �10.1115/1.3647868�. �hal-
01723827�
A Contribution for Virtual Prototyping
of Mechatronic Systems Based on
Real-Time Distributed High
Level Architecture
H. J. Hadj-Amor
e-mail: hassen.hadj-amor@supmeca.fr
T. Soriano
e-mail: thierry.soriano@supmeca.fr
LISMMA—Supmeca Toulon,
Maison des Technologies, Place Georges,
Pompidou, 83000 Toulon, France
Mechatronics is the integration of different sciences and techni-
ques of mechanical engineering, automatic control, electronics,
and informatics. The rapid evolution of the market competitors
requires the reduction of development time of a product while
increasing the quality and performance. It is, therefore, necessary
to increase the efficiency of the design process. To meet this need,
simulation and, especially, virtual prototyping have become a key
technology. It is difficult to find simulation tools are able to ana-
lyze multidependent systems of different areas. However, an envi-
ronment that allows a simulation integrating multidisciplinary
mechatronic systems is necessary. This paper describes a method
of design and simulation of mechatronic systems. First, we iden-
tify the behavior model and its associated 3D geometric model.
The behavior model is seen as a dynamic hybrid system of two
coupled hybrid automata (operative part and control part). Then,
we present OpenMASK and OpenModelica simulators, the
IEEE1516 standard HLA and work related to this distributed
architecture for simulation. In a top-down approach, we present
our method and experiments to integrate HLA functionalities in
these simulators and to distribute the modeling elements of
mechatronic systems. Also, we propose extensions to integrate
real-time for interactive simulations. Finally, we apply our
approach on a representative example of a mechatronic system.
[DOI: 10.1115/1.3647868]
1 Introduction
A mechatronic system is the combination of several compo-
nents from different domains (mechanics, automatic control, elec-
tronics, and embedded control software). This combination makes
possible the generation of small and powerful systems which inte-
grate functions and ability for decisions. However, their design
can be difficult and the development period of such complex sys-
tems has to be as short as possible. Especially, analyzing the
behavior is a difficult task. To face this problem, virtual prototyp-
ing of mechatronic systems can be a good solution. Indeed, virtual
prototypes can help manufacturers to predict behavior so they can
make better design, manufacturing, and business decisions. Vir-
tual prototyping involves a 3D geometric simulation and
MULTI-
PHYSICS
simulation. A first solution consists in coupling subsystem
models within the same environment. This is cosimulation as
described in Ref. [1]. Cosimulation is one of the possible techni-
ques to enable closer interaction between existing submodels into
a more complete model. The most common environment that sup-
plies as a cosimulation framework is
SIMULINK. Many environ-
ments that support
MULTIPHYSICS simulations, such as DYMOLA [2]
or
MULTIBODY, and dynamic systems, such as MSC.ADAMS [3],
provide specific modules for running such cosimulations. Many
methods are used for coupling of dynamic simulations. One
method earlier used is transmission lines modeling (TLM). The
TLM is based on physically motivated time delays and TLM ele-
ments to separate the components in time and enable efficient
cosimulation. This technique was implemented for coupling dif-
ferent subsystems [4–6]. However, these tools are not specialized
in the 3D animation. To keep the accuracy and precision of 3D
graphic simulation, we are going to use two specialized environ-
ments of simulation. Our contribution is situated in the definition
and the implementation of normalized exchanges and synchroni-
zation between two highly efficient open source simulators, one of
them specialized in virtual reality. The goal here is to simulate a
complete environment with many different actors and tools. The
main concerns are not simulation methods but instead standards
and protocols that allow tools to communicate.
In this paper, we present a method based on the high level
architecture (HLA) to make communication possible between the
3D OpenMASK (Modular Animation and Simulation Kit) virtual
prototyping simulator [7] and the
MULTIPHYSICS OpenModelica [8]
simulator. HLA is situated in continuation of the works on cosi-
mulation with respect to disclosing proprietary information about
the subsystem models by introducing a standardized layer to
exchange data without requiring an integrator environment [1].
Using this method, we can facilitate simulating and analyzing
mechatronic systems in a multidisciplinary workgroup. An
approach for modeling and simulation of mechatronic systems is
described in Sec. 2. Section 3 presents the HLA and some related
works. Sections 4 and 5 present briefly OpenMASK and OpenMo-
delica simulators. Section 6 presents solutions to integrate HLA
services in both simulators. Section 7 deals with time manage-
ment. Then, we present an application to test out our approach in
Sec. 8. Lastly, we present a brief discussion in Sec. 9 to improve,
in the future, the accuracy and efficiency of the framework envi-
ronment obtained.
2 Modeling and Simulation for Mechatronics in a
Distributed Architecture
From the functional point of view, a mechatronic system can be
seen as a collaboration of two major parts:
— A control part: It consists of electronic, automatic, and com-
puter technologies. It can be a closed-loop or open-loop
control.
— An operative part: It consists of mechanical and electrome-
chanical parts.
The distinction of the control and operative parts does not only
mean to separate them and understand them independently but
also to understand the links between them. The complexity of
mechatronic systems is due to the integration of several disci-
plines. Accordingly, the behavior of these systems with various
technologies is difficult to model. The control of a mechatronic
system often uses discrete states, and the behavior of the operative
part consists of discrete jumps between continuous states. This
type of behavior is typically that of hybrid dynamic systems. We
choose the hybrid automata formalism for a unique and homoge-
neous modeling of the operative part and the control part. Behav-
iors of the control part and the operative part are modeled by
different hybrid automata, which can be coupled jointly following
the method provided in Ref. [9]. The simulation of a mechatronic
system, thus, has to support, on the one hand, the dynamic
evolution represented by hybrid automata carrying in particular
electromechanical equations and, on the other hand, its graphic
representation. The global behavior is then modeled by hybrid
automata which are implemented in OpenModelica using the
1
HybridAutomataLib [10]. On the other hand, the role of Open-
MASK is to animate 3D physical objects representing the system.
The communication between both simulators is maintained by the
HLA RTI (real-time infrastructure).
In the HLA terminology, we mean by the term “federate,” each
elementary simulator, and by the term “federation” a group of
intereffective federates. Notions of federate and RTI will be
developed in Sec. 3.1.
We identified two federates: one federate for the animation of
3D objects and one behavioral federate, which represents the con-
trol and operative parts of the mechatronic system (Fig. 1). The
first federate is implemented within OpenModelica; the second
one is implemented within the OpenMASK virtual environment
(Fig. 2).
3HLA
3.1 Definitions and Terminology. HLA is defined under the
IEEE standard 1516 for the architecture of interoperable distrib-
uted simulations. The HLA was proposed by the Defense Model-
ing and Simulation Office, instigated by Department of Defence
[11–13].
In France, the ministry of defense and, in particular, the navy
ministry is also interested in this standard.
This architecture has got three objectives:
— making the reuse of elementary simulator easier
— making interoperability between the distributed simulators
easier
— reducing simulation and modeling costs.
The HLA is described by some specifications composed of:
— a series of rules that specifies the responsibilities of the fed-
erates and the federation
— an object model template
— specifications concerning the application programming
interface (
API).
The software elements of an HLA federation are composed of
an implementation of the RTI and some federates. A federation is
a set of federates having a common object model. It is the repre-
sentation of a set of interoperating simulators. The first function
of the federation object model is to specify, in a common and
standard format, the nature of the data exchanged among federates
in the federation. These data include an enumeration of all objects
and interaction classes as well as a specification of the attributes
and parameters characterizing theses classes. A simulation object
model is a specification of the types of information that an indi-
vidual federate could provide to HLA federation as well as the in-
formation that an individual federate can receive from other
federates in HLA federation.
HLA is a specification and not an implementation. There are
several softwares relating to HLA; RTI is the tool for the design
of federation. We were interested in the open source RTIs. We
chose the
CERTI tool developed at ONERA [14,15].
3.2 Related Works. HLA was developed mainly for military
distributed simulations. There are few applications to integrate
HLA in commercial and academic simulators. Difficulties arise
when trying to make these simulators HLA compliant. Military
simulators have been developed as specific tools where HLA
functions may be implemented at the beginning of the develop-
ment. However, HLA functions are not planned to integrate non-
military simulators. Four solutions have been identified to
integrate HLA in simulators in Ref. [16].
In the field of manufacturing systems, we find in Ref. [17]an
environment based on HLA to integrate some simulators. In the
field of control systems, the hybrid simulator AnyLogic integrated
HLA services [17]. Many approaches were proposed to integrate
HLA with
MATLAB. Most of these approaches use wrapper pro-
grams and external libraries to communicate
MATLAB with the
RTI. The implementation of this interface was presented in Ref.
[18]. The project is called the HLA TOOLBOX. In the field of 3D
CAD software, we found an approach proposed in Ref. [18]to
make a 3D simulator HLA compatible. In the field of virtual pro-
totyping, we found an approach presented in Ref. [19] to link the
oRis platform with the RTI. We did not find any application
involving a 3D simulator and a
MULTIPHYSICS simulator and inte-
grating real-time aspects.
4 OpenMASK
OpenMASK is an open source platform for modular applica-
tions development and execution in animation, simulation, and
virtual reality fields. OpenMASK has modular architecture [20].
A simulation with OpenMASK is composed of modules con-
nected to a data bus. Each module can represent an elementary 3D
object or can be a pure behavioral object. The way to program the
behavior of an object is completely left to the user. An Open-
MASK module can also contain inputs=outputs for the exchange
of data. OpenMASK modules can exchange events directly or by
means of the OpenMASK’s bus.
5 OpenModelica
Modelica is an object-oriented language. Its goal is to model
complex physical systems including electric, mechanical, hydrau-
lic, and thermal components [21]. OpenModelica is a free envi-
ronment of modeling, compilation, and simulation, based on a
BSD (Berkeley Software Distribution) license. The current ver-
sion of the OpenModelica environment allows the interactive exe-
cution of most of the expressions, the algorithms and the parts of
Modelica functions as well as the generation of an effective C
code from the models of equations and the Modelica functions.
The C code generated is combined with a library of useful func-
tions, a run-time library and a digital solver differential algebraic
equations. The default integration method for OpenModelica is
the DASSL code as defined by Brenan et al. [22]. In order to inte-
grate event handling in the compiler and run-time system, the
front-end must produce crossing functions and handlers for the
Fig. 1 A HLA federation
Fig. 2 Global approach
2
events; the actual search for zero crossings is left to the solver
[23].
6 Integration of HLA Services in Simulators
6.1 Design of the Federation. A mechatronic system is
made up of several mechatronic subsystems that are composed by
elementary components of various domains. It is possible to
describe every component by an HLA object. Given that we are
only interested in the dynamic state variables, we describe every
mechanical component by an HLA object. Attributes of these
objects are dynamic state variables of the global system. The
OpenModelica federate has to publish attributes of its HLA
objects before the beginning of the simulation. The OpenMASK
federate has to subscribe to all attributes of HLA objects of the
OpenModelica federate. During the simulation, the OpenModelica
federate updates its HLA object attributes by calling the publish
service or by sending interaction. Thereby, the RTI reflects these
attributes to the OpenMASK federate.
6.2 Integration of HLA Services in OpenModelica. We
propose a wrapper, which has to communicate with the simulator
through sockets. This wrapper is implemented in Cþþ and so we
are able to integrate the HLA services to exchange data with the
RTI [24]. It is possible to call functions implemented in
C or FOR-
TRAN
language from a Modelica program [25]. We use this Model-
ica property to exchange data with a wrapper by using sockets. A
socket is a unique identifier representing an address on the net-
work. The socket address is specified by the host name and the
port number. We use the TCP-IP protocol to assure data transport
(packages) between the process server (the wrapper) and the client
(the simulation under OpenModelica).
6.2.1 Interface From OpenModelica to the RTI Communication
from OpenModelica to the wrapper. The wrapper is implemented
as a TCP server. The simulation calls the external
C functions to
connect to the wrapper and exchange data with it. Once the con-
nection is established, the simulation sends information to the
wrapper server. This last one can also send back information to
the simulation. We developed five basic functions for the commu-
nication process: Function createSocket() to exchange the simula-
tion data, function sendMessage() to send a message, function
receiveMessage() to receive a message, function recMsgBlock()
to freeze OpenModelica, and function clean() to close the connec-
tion socket. We created a Modelica library that we called Commu-
nicationLib. This library contains a socket class as well as the
wrapped functions using the external functions defined in C. The
socket class is customizable. We can modify the IP address and
the port. In our case, we use the localhost address because Open-
Modelica and its wrapper have to run on the same machine. We
choose a fixed time step to send and receive data. The wrapper
representing the TCP server is implemented in Cþþ (Fig. 3). A
socket server is created and is listening for connection requests.
When a connection request is received, a connection is established
and the wrapper can receive the data from the simulation under
OpenModelica. Each value received is decrypted. The name of
the variable is extracted as well as its value. For that, we devel-
oped a general Modelica module that we called RemoteController
(Fig. 3). This module represents a connection point between
OpenModelica and any external program using a TCP server.
Every hybrid automaton represents a component of the global
system. An hybrid automaton of the operative part contains a vec-
tor of state variables. Each hybrid automaton of the operative part
is represented by an object in the wrapper. The attributes of this
object are the state variables of the corresponding hybrid automa-
ton. Once the wrapper receives values of the state variables of an
hybrid automaton, it allocates them to the attributes of the corre-
sponding objects.
Communication from the wrapper to the RTI. As the OpenMo-
delica wrapper is implemented in Cþþ, we chose that it calls
directly the functions of the libRTI library, which includes the
HLA services, to join the federation, to publish and=or subscribe
to attributes, etc. More specifically, all requests sent by a federate
to the RTI take the form of methods calls to the object RTIAmbas-
sador within libRTI.
6.2.2 Interface From the RTI to OpenModelica. Another task
that the wrapper has to carry out is the implementation of the fed-
erate ambassador class to provide callbacks functions. This last
one is responsible in each federate for all the data received from
the RTI. Any data received by the FederateAmbassador object can
be sent to the simulation under OpenModelica through sockets.
The RTI sends messages to the wrapper by calling functions.
These functions are called callbacks and they are defined in the
wrapper.
6.3 Integration of HLA Services in OpenMASK. An Open-
MASK simulation is a set of Cþþ modules that interact. These
modules are compiled before being executed. The idea is to inte-
grate the HLA services in one or more of these modules before
they are compiled. As the HLA RTI (
CERTI) used is a Cþþ library,
we have no problem of compatibility.
An OpenMASK simulation is organized in a tree simulation
composed of modular elements called the simulation modules.
These modules are connected to a bus which allows them to
exchange messages and=or signals. An OpenMASK module has a
predefined architecture. It is a Cþþ class, which can contain
generic methods: Init(), compute(), processEvent(), etc. Our
approach to integrate HLA services in an OpenMASK simulation
is to create an overall module that we called HLAC (HLA com-
munication). This latter invokes HLA services to communicate
with the HLA RTI. The HLAC module can also contain
inputs=outputs for the data exchange. At each step of simulation,
the general module can read all the state variables of each visual
module to allocate new values by exchanging events or signals
through OpenMASK proper bus.
6.3.1 The HLAC Module. The HLAC module is composed of
three parts: A first part to detect events, to catch objects attributes
from the simulation model, and to transform them into calls of
RTIAmbassador functions (Fig. 4). This part is called LRC (local
RTI component). The second part catches messages and updates
from RTI using callbacks functions declared in the class Federa-
teAmbassador. This part is called FedCode (federate code). The
third part is the internal simulation model which sends updates to
other OpenMASK modules and receives events from them.
LRC. The Init() method is called one time like the constructor
to initialize the attributes of the HLAC object. We use this method
to invoke some HLA services to create and=or join a federation,
to get handles of HLA items (HLA objects, HLA interactions,
object attributes, interaction parameters, etc.) and to publish and
Fig. 3 OpenModelica wrapper
3
subscribe to some HLA items. In our approach, to create a federa-
tion, the LRC calls the createFederationExecution() function. To
join the federation, the LRC calls the joinFederationExecution()
function with three parameters (federate name, federation name,
and a pointer to the class implementing the federate callbacks).
Before a federate can produce any data, it must declare its intent
to publish. Interaction between a user and the simulation or colli-
sion detection is represented by an HLA interaction class. To
receive values for instance attributes, the federate must first sub-
scribe to the desired class attributes. To receive interactions of a
certain class, the federate must subscribe to that class of interac-
tions. The actions carried out by a federate only once are inte-
grated in the Init() method. Dynamic actions “performed in a
cyclical manner” are implemented in the compute() method.
Indeed, the compute() method is executed at a frequency attrib-
uted to each OpenMASK module at the beginning of the simula-
tion. During the simulation, the HLAC module sends data to the
RTI on updating its attributes or sending interactions. Collision
detection during the simulation or an interaction with the user trig-
gers an event. Due to this, the HLAC module can send interac-
tions to other federates or update some of its attributes to inform
other federates about the interaction or the collision. Once the end
of simulation reached, it calls the resignFederationExecution()
service to leave the federation.
FedCode. The FedCode part catches events and updates from
the RTI using callback functions declared in the FederateAmbas-
sador class. To use them, HLAC class must inherit from the Fed-
erateAmbassador. These callback functions are implemented in
the HLAC module and outside the generic methods. The attribute
values received through the callbacks are used to animate the 3D
objects in OpenMASK. Each 3D object is represented by an
OpenMASK module (visual module). It receives updates from the
HLAC module via messages through the OpenMASK bus (see
Fig. 4).
6.3.2 Communication Sequence Between the OpenMask
federate (HLAC) and the RTI. We identified six steps of commu-
nication between the HLAC module and the RTI: Create and=or
join federation, initialization, publication and subscription, syn-
chronization, update attributes, and advancing in time and the last
step is the simulation end (Fig. 5). The OpenMASK federate
begins by joining the federation if it was already created. Other-
wise, it can create the federation and join it. Then, the federate
gets the handles of HLA items by sending requests to the RTI.
The returned handles are unique between the RTI and the federate.
The federate can at this stage declare its intent to publish or sub-
scribe. After that, the federate requests to synchronize its execu-
tion with other federates. Once all federates are synchronized, the
Fig. 4 The HLAC module
Fig. 5 A generic sequence diagram for every simulation
4