S I M U L AT I O NNEWS EUROPE

Journal on Developments andTrends in Modelling and Simulation

Special Issue

Volume 16 Number 2 September 2006, ISSN 0929-2268

ARGESIM

SNE

Special Issue

Parallel and Distributed

Simulation Methods

and Environments

bbb

++ Editorial - Content +++SN

E 16

/2,

Sept

embe

r 20

06

Content

Editorial SNE Special Issue Parallel and Distributed Simulation Methods and Environments;T. Pawletta, S. Pawletta ... 2

Call for SNE Special Issue 2007 Verification andValidation in Modelling and Simulation; S. Wenzel ... 3

Overview about the High Level Architecture for Modelling and Simulation and Recent Developments; S. Straßburger ... 5

Lookahead Computation in G-DEVS/HLA Environ-ment; G. Zacharewicz, C. Frydman, N. Giambiasi ... 15

Parallel Simulation Techniques for DEVS/Cell-DEVSModels and the CD++ Toolkit; G. Wainer, E. Glinsky ... 25

SCE based Parallel Processing and Applications in Simulation; R. Fink, S. Pawletta, T. Pawletta, B. Lampe ... 37

HLA Applied to Military Ship Design Process; C. Stenzel, S. Pawletta, R. Ems, P. Bünning ... 51

Co-simulation of Matlab/Simulink with AMS Designerin System-on-Chip Design; U. Eichler, U. Knöchel, S. Altmann, W. Hartong, J. Hartung ... 57

Parallel Computation in Blood Flow Simulation usingthe Lattice Boltzmann Method; S. Wassertheurer, D. Leitner, F. Breitenecker, M. Hessinger, A. Holzinger ... 64

ARGESIM Benchmark on Parallel and DistributedSimulation; F. Breitenecker, G. Höfinger, R. Fink, S. Pawletta, T. Paletta, ... 69

SNE Editorial Board

Felix Breitenecker (Editor-in-Chief), Vienna Univ. of Technology, Felix.Breitenecker@tuwien.ac.at

Peter Breedveld, University of Twenty, Div. Control Engineering, P.C.Breedveld@el.utwente.nl

Francois Cellier, ETH Zurich, Inst. f. Computational Science / University of Arizona, fcellier@inf.ethz.ch,

Russell Cheng, Fac. of Mathematics / OR Group, Univ.of Southampton, rchc@maths.soton.ac.uk

Rihard Karba, University of Ljubljana, Fac. Electrical Engineering, rihard.karba@fe.uni-lj.si

David Murray-Smith, University of Glasgow, Fac. Electrical & Electronical Engineering; d.murray-smith@elec.gla.ac.uk

Horst Ecker, Vienna Univ. of Technology.Inst. f. Mechanics, Horst.Ecker@tuwien.ac.at

Thomas Schriber, University of Michigan, Business Schoolschriber@umich.edu

Sigrid Wenzel, University of Kassel, Inst. f. Production Technique and Logistics, S.Wenzel@uni-kassel.de

Guest Editors Special Issue Parallel and Distributed Simulation Methods and EnvironmentsThorsten Pawletta, pawel@mb.hs-wismar.deSven Pawletta, s.pawletta@et.hs-wismar.de

Res. Group Computational Engineering and Automation, Wismar University, 23952 Wismar, GermanyWWW.MB.HS-WISMAR.DE/cea

SNE Contact

SNE-Editors / ARGESIM c/o Inst. f. Analysis and Scientific Computation Vienna University of Technology Wiedner Hauptstrasse 8-10, 1040 Vienna, AUSTRIATel + 43 - 1- 58801-10115 or 11455, Fax - 42098sne@argesim.org; WWW.ARGESIM.ORG

Dear readers, We are glad to present the first SNE Special Issue - a Special Issue on ‘Parallel and Distributed Simulation Methods and Envi-ronments’. The idea for special issues was born in ASIM, the German Simulation Society. As there was and as there still is aneed for state-of-the-art publications in topics of modelling and simulation, ASIM first tried to publish monographs on thissubject. But publication of such books showed disadvantages: too slow production time, too high costs, and lack of publicationissues. ASIM, seeking for alternatives, contacted ARGESIM with the idea of SNE Special Issues - while ARGESIM itself thoughton Special Issues, because of lack in publication space in the regular SNE issues. Now, one year after the first contact, we canpresent the first Special Issue, edited by Thorsten & Sven Pawletta from University Wismar, Germany. The editorial policy of SNE Special Issues is to publish high quality scientific and technical papers concentrating on state-of-the-artand state-of-research in specific modeling and simulation oriented topics in Europe, and interesting papers from the world widemodeling and simulation community. This Special Issue ‘Parallel and Distributed Simulation Methods and Environments’ (SNE16/2), will be sent to all ASIM members - together with the regular SNE 16/1 (SNE 46), and sample copies will be sent to otherEuropean Simulation Societies; furthermore, it is available on basis of an individual subscription of SNE - SNE Special Issues areopen for everybody, for publication and subscription (not only for ASIM). We think also on Special Issues publishing selectedpapers from EUROSIM conferences.We hope, you enjoy this Special Issue, which presents state-of-the-art in parallel and distributed simulation, from theory with lookaheadformulas via implementation with HLA and other systems to applications in ship desgin and blood flow simulation.It is planned to publish a SNE Special Issue each year, for 2007 a Special Issue on ‘Verification and Validation’ (Guest EditorSigrid Wenzel, University Kassel) is scheduled (SNE 17/2). I would like to thank all people who helped in managing this firstSpecial Issue, especially the Guest Editors, Thorsten and Sven Pawletta from Wismar University.

Felix Breitenecker, Editor-in-Chief SNE; Felix.Breitenecker@tuwien.ac.at

Editorial Info - Impressum

SNE Simulation News Europe ISSN 1015-8685 (0929-2268).Scope: Development in modelling and simulation, benchmarks on modellingand simulation, membership info for EUROSIM and Simulation Societies.Editor-in-Chief: Felix Breitenecker, Inst. f. Analysis and Scientific Computing, Mathematical Modelling and Simulation, , Vienna University of Technology, Wiedner Hauptstrasse 8-10, 1040 Vienna, Austria; Felix.Breitenecker@tuwien.ac.atLayout: A. Breitenecker, ARGESIM TU Vienna / Linz; Anna.Breitenecker@liwest.atPrinted by: Grafisches Zentrum TU, Wiedner Hauptstr. 8-10, A-1040, WienPublisher: ARGESIM and ASIMARGESIM, c/o Inst. for Analysis and Scientific Computation, TU Vienna, Wiedner Hauptstrasse 8-10, A-1040 Vienna, Austria, and ASIM (German Simulation Society), c/o Wohlfartstr. 21b, 80939München© ARGESIM / ASIM 2006

++ Editorial Special Issue +++

2

This is the first Special Issue of SNE, edited by mem-bers of the ASIM working group Methods of Modelingand Simulation . The new SNE Special Issue Series hasbeen introduced as an extension of the regular SNE.The aim is to publish high quality scientific and tech-nical papers concentrating on a specific topic. Usingthis approach the SNE Special Issues will present thestate of research in specific modeling and simulationoriented topics in Europe, and interesting papers fromthe world wide modeling and simulation community.This Special Issue of SNE is devoted to Parallel andDistributed Simulation Methods and Environmentsand includes seven selected papers and a call for abenchmark in distributed and parallel simulation.

The development of parallel and distributed simula-tion methods and software tools has been stronglyinfluenced by High Level Architecture (HLA) in re-cent years. HLA has its origins in the military simula-tion community. As a consequence of its openness andgeneric character it has also had a significant impacton non-military applications and is now an IEEE stan-dard for distributed simulation. The first paper by Strassburger (Fraunhofer InstituteMagdeburg, Germany) introduces the history of HLA,presents its main concepts and discusses recent deve-lopments. It provides enough background informationfor non-experienced readers in this field for the twofurther HLA related contributions in this journal.

The second paper and the third paper discuss specificparallel and distributed simulation approaches for Dis-crete EVent specified Systems (DEVS) and the associa-ted simulator algorithms. Zacharewicz, Frydman andGiambiasi (University Marseille, France) investigatenew lookahead computation methods in the G-DEVS/HLA environment. G-DEVS is a specific exten-sion of the DEVS theory and of DEVS simulator algo-rithms for hybrid dynamic systems. Continuous and dis-crete model components and their associated simulatorscan be located on different computers and integratedinto a global simulation model using HLA technology.

The contribution by Wainer and Glinsky (Carleton Uni-versity, Ottawa, Canada) investigates parallel simulationtechniques for DEVS and Cell-DEVS models that com-bine cellular automata with DEVS theory. In their paral-lel simulation environment, CD++, the DEVS simula-tion algorithms are modified and combined with conser-vative and optimistic synchronization algorithms.

Scientific and Technical Computing Environments(SCEs) such as MATLAB, Scilab or Octave are es-sential tools in today's computational engineering andscience. Especially optimization and simulation arewell supported by integrated algorithms and subsys-tems like Simulink, Scicos or Stateflow. The fourthpaper by Fink, Pawletta and Lampe (Wismar Univer-sity, Germany) gives a detailed overview about SCEbased parallel processing. In this paper, a new taxo-nomy on SCE based parallel processing is presented,followed by the identification and assignment of morethan 30 existing projects. Furthermore, simulation andoptimization applications which have been paralleli-zed under usage of SCEs are discussed. Parallel run-time results as well as general application characteri-stics are presented.

The fifth, sixth and seventh papers have been moti-vated by engineering applications.

Stenzel, Pawletta, Ems and Bünning (Wismar Univer-sity and MTG Marinetechnik GmbH, Hamburg; Ger-many) describe an application, where existing real-world software components, mainly written in Fort-ran, have to be integrated into an HLA compliantfederation. Fortran/HLA integration approaches areexamined in detail, whereas experiences in the field ofMATLAB/HLA connectivity serve as design pattern.

The contribution by Eichler, Knöchel, Altmann, Har-tong and Hartung (Fraunhofer Institute Dresden and Cadence Design Systems GmbH, Feldkirchen; Ger-many) describes the coupling of different simulatorsvia TCP/IP network socket connection. The imple-mentation and application of such a co-simulation isdescribed in detail for the simulators MAT-LAB/Simulink and AMS Designer.

The contribution by Leitner, Wassertheurer, Breiten-ecker, Hessinger and Holzinger (ARC Seibersdorfresearch GmbH, Vienna; Vienna University of Tech-nology; Medical University Graz; Austria) presents aLattice-Boltzmann model (LBM) for solving fluidmechanical problems in engineering and biomedicalapplications. The investigated model is relevant forblood flow simulation because it uses Reynolds andWomersley numbers found in haemodynamics with arealistic time dependent pressure gradient as a bound-ary condition. A big advantage of LBM is the possi-bility of easy parallelization.

SNE

16/2

, Se

ptem

ber

2006

Editorial SNE Special Issue

Parallel and Distributed Simulation Methods and Environments

Therefore different approaches and implementationsare discussed and compared with respect to paralleli-zation efficiency.

Furthermore, this SNE Special Issue publishes a callfor a benchmark on parallel and distributed simula-tion tasks. This new ARGESIM Benchmark on Paral-lel and Distributed Simulation extends the ARGESIMComparison on Parallel Simulation Techniques from1994. The three tasks of this benchmark are moregeneral, so that not only simulation software is ad-dressed, so that also different algorithms for solvingthe tasks can be used, and so that different strategiesfor parallelization or distribution of the tasks can beset up and compared.

This SNE Special Issue on Parallel and DistributedSimulation Methods and Environments (SNE 16/2),will be sent to all ASIM members - together with theregular SNE 16/1 (SNE 46), and sample copies will besent to other European Simulation Societies (withordering offer). Furthermore, it is available on basis ofan individual subscription of SNE.

It is planned to publish a SNE Special Issue each year.We would like to draw your attention to the Call forPapers for the next special issue (see below) on Veri-fication and Validation in Modeling and Simulation,edited by the ASIM working group Simulation in Pro-duction and Logistics (Guest Editor Sigrid Wenzel,University Kassel).

Finally, we would like to thank all authors, who havecontributed to this special issue, our co-workers atWismar University for various support, the ARGE-SIM people at Vienna University of Technology foreditorial support, and F. Breitenecker (Editor-in-Chiefof SNE) for good co-operation.

Thorsten Pawletta & Sven PawlettaGuest Editors SNE Special Issue Parallel and Distributed Simulation Methods and EnvironmentsRes. Group Computational Engineering and Automation, Wismar UniversityPF 1210, 23952 Wismar, GermanyWWW.MB.HS-WISMAR.DE/cea

SNE 16/2, Septem

ber 2006

3

+++ Editorial Special Issue / Call for SNE Special Issue ++

Simulation is an important method which helps totake right decisions in system planning and operation.Building high-quality simulation models and usingthe right input data are pre-conditions for achievingsignificant and usable simulation results. For this purpose, a simulation model has to be well-defined, consistent, accurate, comprehensive andapplicable. The quality criteria can be proved by veri-fication (building a model in the right way) and vali-dation (building the right model).

The ASIM-Working Group Simulation in Productionand Logistics which has worked on this topic sincethree years accommodates the increased significanceof verification and validation and will publish theforthcoming Special Issue of Simulation NewsEurope (SNE) on this topic.

Papers on the following topics will be welcome:

- Procedure Models for Verification and Validation

- Methods for Verification and Validation- Certification and Accreditation- Information / Data Acquisition for Simulation

Models and their Verification and Validation

- Verification and Validation - Documentation Aspects

- Credibility- Automatic Verification and Validation- Case Studies and Practical Experiences

The Guest Editor of this SNE Special Issue (SNE17/2), Prof. Dr. Sigrid Wenzel from University Kassel,invites for submitting contributions.

Contributions should not exceed 8 pages and shouldbe mailed directly to the editor not later than March31, 2007; contributions will be peer reviewed (templa-tes available at ASIM and ARGESIM web page -WWW.ASIM-GI.ORG, WWW.ARGESIM.ORG).

Sigrid WenzelGuest Editor SNE Special Issue

Verification and Validation in Modeling and Simulation

Department of Mechanical EngineeringUniversity of Kassel, Kurt-Wolters-Strasse 3D-34125 Kassel, Germanys.wenzel@uni-kassel.deWWW.UNI-KASSEL.DE/fb15/ipl/pfp/

Call for Contributions SNE Special Issue 2007

Verification and Validation in Modelling and Simulation

sloim

EUROSIM - Federation of European Simulation Societies

DEADLINES:

Proposal special sessions and tutorials:

Submission of extended abstracts:

cceptance:

Early registration:

Submission of camera ready papers:

Hotel Reservation:

for

-

9

9

Feb. 2007

April 2007

May 2007

June 2007

July 2007

July 2007

1

30

11

27

N of aotification

VENUE:

University of Ljubljana, Faculty of ElectricalEngineering, Ljubljana, Slovenia

CONGRESS COMMITTEE:

Borut Zupančič, EUROSIM,

Rihard Karba, SLOSIM

niv. of Lj. . . .

Felix Breitenecker, of

president of chair

president of

Tomaž Slivnik, U , Fac of El Eng , dean

ASIMpresident

INTERNATIONAL PROGRAMME COMMITTEE:R. Karba (SI), chairD. Al – Dabass (UK),M. Alexik (SK),I. Bausch-Gall (DE),L. Bobrowski (PL),W. Borutzky, (DE)J. Božikov (HR),F. Breitenecker (AT),P. Bunus (SE),P. Cafuta (SI),R. Cant (UK),A. Carvalho Brito (PT),G. Cedersund (SE),F. Cellier (CH),V. Čerić (HR),E. Dahlquist (SE),B. Elmegaard (DK),P. Fritzson (SE),J.M. Gir -

RO

UI

čić (SI),K. Juslin (FI),E. Juuso (FI),H. Karatza (GR),E. Kindler (CZ),M. Kljajić (SI),M. Klug (AT),

J. Kocijan (SI),J. Kunovsky (CZ),F. Lebon (FR),B.H. Li (CN),H.X. Lin (NL),F. Maceri (IT),W. Maurer (CH),Y. Merkuryev (LV),A. Munitić (HR),D. Murray-Smith (UK),S. Oharu (JP),A. Orsoni (UK),K. Panreck (DE),T. Pawletta (DE),H. Pierreval (FR),J. Pollard (UK),C.Z. Radulescu (RO),M. Radulescu (RO),F. Rocaries (FR),P. Schwarz (DE),M. Savastano (IT),W. Smari (US),F. Stanciulescu (RO),G. Szucs (HU),M. Šnorek (CZ),I. Troch (AT),S. Wenzel (DE),W. Wiechert (DE),E. Williams (US),R. Zobel (UK, TH),B. Zupančič (SI),L. Žlajpah (SI)

on Sierra (ES),Y. Hamam (F ),F. Hartescu (R ),A. Heemink (NL),V. Hlupic (UK),F. Javier Otamendi (ES),A. Jávor (H ),K. Jezernik (S ),Ð. Juri

ORGANISERS:

- SLOSIM - Slovene Society for Simulation and Modelling

University of Ljubljana, Faculty of Electrical Engineering

EUROSIM societies CROSSIM, CSSS,DBSS, FRANCOSIM, HSS, ISCS, SIMS, UKSIM, AES,PSCS, ROMSIM

CASS Chinese Association for System Simulation,

ECMS European Council for Modelling and Simulation,

JSST Japan Society for Simulation Technology,

LSS Latvian Simulation Society,

SCS The Society for Modeling and Simulation Int.

-

- member : ASIM,

-

-

-

-

-

CO-SPONSORS

EXHIBITION

:

:

Exhibitors with software, hardware and books from thearea of M&S are cordially invited to participate.

CONTACTS:Borut Zupančič

Rihard Karba

, congress chair, IPC chair

University of Ljubljana, Faculty of Electrical EngineeringTržaška 25, SI-1000 Ljubljana, SloveniaPhone: +386 1 4768 306E-mail: borut.zupancic@fe.uni-lj.siE-mail: rihard.karba@fe.uni-lj.siAlenka Kregar, registration, accommodationCankarjev dom, Cultural and Congress CentrePrešernova 10, SI-1000 Ljubljana, SloveniaPhone:+386 1 241 7133Fax: +386 1 241 7296E-mail: alenka.kregar@cd-cc.si

M&S applications: aerospace, automotive systems andtransportation, agriculture, architecture, biopharmacy,biomedicine, bioinformatics, genomics, business, appliedchemistry, civil engineering, communications, ecologicaland environmental systems, economics, econometrics,economics of M&S, education, electrical engineering,geophysical systems, industrial processes, logistics,manufacturing systems, maintenance, reliability, marinesystems, materials modelling and simulation, mechanicalengineering, mechatronics, meteorology/climate, militarysystems, organisational processes, process engineering,traffic/transportation power systems, applied psychology,computational fluid dynamics, training simulators, socialsystems biology, sciences, robotics, water managementand treatment, mobile robotics, seismism, pulp & paper,supply chains, lifecycle management plant data

,

and

About EUROSIM:

EUROSIM is the Federation of European SimulationSocieties and EUROSIM congress (triennial event) is one of the most important activities of thefederation.

ore information about EUROSIM :

the organization a

For m seewww.eurosim.info

PROGRAMME:

SCOPE AND TOPICS:

The me

modelling andsimulation of complex, large scale, distributed, hybrid,hierarchical, stochastic, control, expert, adaptive, fuzzy,decision support, multivariable, multiagent, reconfigurable,agent based, knowledge based, real time, queuingsystems, scheduling, parallel processing concepts, highperformance computing, M&S system architectures, neuralnetworks, model validation and verification, simulation life-cycle evolution, genetic algorithms, man-in-the loopsimulation, hardware-in-the loop simulation, nestedsimulation models, distributed enterprise simulation, datamining, bond graphs, simulation with Petri nets, discreteevent simulation, statistic modelling, component basedmodelling, object oriented modelling, mathematical/numerical methods in simulation, graphical modelling,nano technology modelling, embedded and firmwaremodelling, middleware architecture modelling,visualisation, graphics and animation, modelling andsimulation tools, WEB based simulation, human behaviourrepresentation techniques, virtual reality and virtualenvironments, CAD/CAM/CIM/CAE, experiential digitalmedia, future of M&S

EUROSIM 2007 scientific program consists of:Plenary lectures, Regular sessions, Special sessions,Posters, Students’ competition and Tutorials. Papers will bepublished in two Proceedings Volumes: Volume 1: Book ofAbstracts, Volume 2: DVD volume with full papers andmultimedia files.

The scope includes all aspects of continuous, discrete(event) and hybrid modelling, simulation, identification andoptimisation approaches. So the common denominator isproblems solving with modelling and simulation in a waythat can be useful also for solving other problems in similaror different areas. Contributions from technical(engineering) areas but also from nontechnical areas arewelcome.

M&S methods and technologies:

CALL FOR PAPERS CALL FOR PAPERS

September 9-13, 2007, Ljubljana, Slovenia

September 9 - 13, 2007, LJUBLJANA, SLOVENIA

http://www.eurosim2007.org

on Modellin and Simulationon Modellin and Simulation

+++ HLA - High Level Architecture for Modelling and Simulation ++SN

E 16/2, September 2006

5

Introduction and Motivation

The development of the High Level Architecture forModeling and Simulation (HLA) was initiated by theU.S. Department of Defense (DoD) in 1995 out of theneed for a common high-level simulation architecture.The standard was supposed to facilitate the interop-erability and reusability of all types of simulation usedand sponsored by the DoD.

The necessity of the standard is derived from the com-plexity and variety of simulation applications in useand the manifold of expectations towards simulationapplications. They include different levels of abstrac-tion, different levels of interactivity, different tem-poral behavior, etc. In essence, no single monolithicsimulation application could fulfill all requirements ofall users.

Considering the different simulation applica-tions inuse, no one could foresee all their potential usage andcombinations in advance. Thus, the idea of a modular,composable approach for building federations ofsimulations was born which eventually led to thedevelopment of the HLA.

HLA's main objective was to provide an open archi-tecture offering services for interoperability and re-usability. The architecture has no limitations towardsa specific simulation paradigm. It is not even limitedto simulation applications, rather it offers interopera-bility to all kinds of programs. However, HLA provi-des specific interoperability support services toaccommodate specific needs of simulation applica-tions. With that, HLA supersedes general interopera-bility standards like CORBA or DCOM.

Initiated as a standard in the military simulation commu-nity the development of the HLA has been overseen bythe Defense Modeling and Simulation Office (DMSO)for the U.S. DoD. DMSO has deliberately taken a veryopen approach in the definition and accessibility ofHLA and has sponsored publicly available softwareimplementations of the HLA software.

With this policy DMSO has ensured a broad com-munity involvement in the development of HLA,which can be seen as a cornerstone to its rather goodacceptance and adoption. In the military simulationdomain HLA is a mandatory standard not only in theU.S., but also throughout most NATO countries.

HLA involvement of the civilian simulation commu-nity has mostly originated from academia [1] and hasbeen rather research oriented. Significant efforts havebeen focused on using HLA as a standard for inter-operability between commercial of the shelf simula-tion packages [2,3,4].

An important joint research project in the field of civi-lian HLA applications was the IMS Mission project.Its focus was on adopting HLA as a standard for de-sign, planning and operation of globally distributedenterprises. One outcome was a concept and solutionfor distributed supply chain simulation [5].

Serious practical applications of HLA have been inve-stigated by several companies, among them DaimlerChrysler in the automotive sector [6]. Especially forthe automotive industry with its large supplier net-works and rather advanced use of digital planning andsimulation methods within their Digital Factory eff-orts, HLA can play a substantial role for providingplug-and-play simulation interoperability.

Overview about the High Level Architecture forModelling and Simulation and Recent Developments

Steffen Straßburger, steffen.strassburger@iff.fraunhofer.deFraunhofer Institute for Factory Operation and Automation, Magdeburg, Germany

The High Level Architecture for Modeling and Simulation, or HLA for short, is an IEEE standard for distribu-ted simulation. It focuses on interoperability and reusability of the components (called federates) and offerstime management interoperability as well as sophisticated data distribution concepts. HLA has its origin in themilitary simulation community where one of its major tasks is the networking of military training simulators.However, due to its openness and generic character it also has a large impact on non-military distributed simu-lation applications. Due to these facts, HLA can still be regarded the state-of-the-art standard for distributedsimulation. This article introduces the background and history of HLA, introduces its main concepts, anddiscusses recent developments. A summary and evaluation of the future of HLA concludes this contribution.

1 A Short History of HLA

Research in the field of distributed simulation has a longtradition. Parallel distributed event simulation (PDES)is one important branch of distributed simulation prima-rily driven from the civilian simulation communitywhich aims at performance and speedup issues. Conser-vative and optimistic synchronization protocols weredeveloped to handle possible causality violations bet-ween simulations. In the military simulation commu-nity, the Distributed Interactive Simulation (DIS) tech-nology was developed primarily for the connection ofreal-time training simulators. DIS is defined in the IEEE1278 standard since 1993. Another standard for the con-nection of constructive military simulations was theAggregate Level Simulation Protocol (ALSP).Outside the simulation domain, standards for distributedcomputing like the Parallel Virtual Machine (PVM) andthe Message Passing Interface (MPI) have been develo-ped which also influenced the field of distributed simu-lation. The HLA combines its predecessor technologiesfrom the military sector, DIS and ALSP, and is the desi-gnated standard architecture for all U.S. DoD modelingand simulation activities. The HLA development startedin 1995 with the DoD Modeling & Simulation MasterPlan which demanded to ‘establish a common high-level simulation architecture to facilitate the interopera-bility of all types of models and simulations ..., as wellas to facilitate the reuse of M&S components’.

The timeline of the development of the HLA is depic-ted in Figure 1. The base definition of the HLA 1.0Standard in August 1996 can be regarded the first sta-ble HLA definition. Shortly after its release, differentversions of the RTI software developed under DMSOsponsorship became publicly available. This softwarewas distributed freely in the community and includedan RTI Help Desk as a support infrastructure for main-taining the software. The next major release of the HLAstandard was HLA 1.3 in February 1998. This versionof the standard is still quite commonly in use today inmany simulation applications. Two RTI developmentsfollowing this 1.3 release of the standard were made

publicly available in the following time, the first beingRTI 1.3 in 1998, the next being RTI 1.3 NG in 1999.The latter release offered improved performance andis still available today from the Virtual TechnologyCorporation as RTI NG Pro. The HLA 1.3 release for-med the base for further standardization efforts.Among them was the adoption of HLA by the OMGas facility for distributed simulation.The most important standardization activity was therelease of the IEEE version of the HLA standard. Thisrelease is in most parts similar to HLA 1.3, but con-tains several needed improvements which surfaced inthe practical use of HLA 1.3 [7]. Also, some modifi-cations needed in order to comply with IEEE require-ments were made.

The year 2002 marked the end of a transition phase inwhich DMSO had led (and sponsored) the efforts todevelop HLA. Having become an IEEE standard thefurther development of HLA was given into the handsof the Simulation Interoperability Standards Organi-zation (SISO). SISO originated over ten years ago with the DistributedInteractive Simulation (DIS) Workshops and was sincethat time focused on creating standards for simulationinteroperability. SISO is a volunteer organization withmembers from industry, military and academia.Besides hosting the Simulation Interoperability Work-shops (SIW) which are organized three time a year(two in the U.S.A, one in Europe) SISO hosts a Stan-dards Activity Committee (SAC) which oversees thework of several Product Development Groups (PDG).PDGs are the actual groups of people developing stan-dards for simulation interoperability. Most of theirwork is based on HLA, including its future refinementand development of standards. The most important PDG is the HLA-Evolved Initia-tive as it oversees the review of the IEEE 1516 speci-fication. Many new potential HLA requirementshave been identified based on feedback from thevarious domains and application areas. The PDGseeks to address these requirements via a formal

open review of the IEEE 1516 series of specifications.

++ HLA - High Level Architecture for Modelling and Simulation +++SN

E 16

/2,

Sept

embe

r 20

06

6

Tim e

1996 1997 1998 19991995

05/9705/97DM SO RTI1.0

12/9612/96RTIF.0

03/9503/95:InitialDef.

HLA

08/9608/96:Base Def.HLA V1.0

01/98DM SORTI1.3

20012000

02/9802/98ReleaseReleaseHLA HLA V1.3

11/97OM D-Tools

20032002 20052004

11/9811/98OM G OM G FacilityFacilityforDSforDS

09/0009/00IEEE 1516IEEE 1516

12/0112/011.Version1.VersionofPitch RTIofPitch RTI

9/99DM SO

RTI1.3NG

09/02DM SO

term inatessponsoring

2004HLA-Evolvedinitiative starts

03/0303/031516 Certified RTI1516 Certified RTI

(Pitch)(Pitch)

Tim e

19961996 19971997 1998 199919991995

05/9705/97DM SO RTI1.0

12/9612/96RTIF.0

03/9503/95:InitialDef.

HLA

08/9608/96:Base Def.HLA V1.0

01/98DM SORTI1.3

2001200120002000

02/9802/98ReleaseReleaseHLA HLA V1.3

11/97OM D-Tools

2003200320022002 2005200520042004

11/9811/98OM G OM G FacilityFacilityforDSforDS

09/0009/00IEEE 1516IEEE 1516

12/0112/011.Version1.VersionofPitch RTIofPitch RTI

9/99DM SO

RTI1.3NG

09/02DM SO

term inatessponsoring

2004HLA-Evolvedinitiative starts

03/0303/031516 Certified RTI1516 Certified RTI

(Pitch)(Pitch)

Figure 1: HAL development timeline.

As part of this process, the PDG will incorporate thoseaspects raised in the DoD Interpretations Documentfor IEEE 1516 [8] and a Dynamic Link CompatibleHLA API for IEEE 1516.1.

2 Major Concepts of HLA

In order to facilitate interoperability and reusability,HLA differentiates between the simulation functiona-lity provided by the members of the distributed simu-lation and a set of basic services for data exchange,communication and synchronization. Figure 2 givesan functional overview of a distributed simulationunder the HLA paradigm.

In HLA, individual simulations and other participants ofa distributed simulation are referred to as federates.Federates which are supposed to co-operate togetherunder certain guidelines and a defined object modelform a so-called federation. Federates use a commonruntime infrastructure (RTI) for communication. TheRTI is a piece of software which can be regarded as adistributed operating system add-on. HLA defines a bi-directional interface between federates and the RTI. Asingle run is referred to as a federation execution.

The current version of the High Level Architecture forModeling and Simulation, or HLA for short, is formallydefined in the three key documents of IEEE standard 1516.

These documents are- 1516-2000: Framework and Rules - 1516.1-2000: Federate Interface

Specification- 1516.2-2000: Object Model Template

(OMT) SpecificationAll three elements are briefly discussed in detail in thefollowing sections.

2.1 HLA Rules

The HLA Rules define the required behavior of afederation and its federates and are thus part of theformal HLA compliance definition. There are 5 rulesfor federations and 5 for federates ([11]).

Rules for federations:

1. Federations shall have an HLA FOM, docu-mented in accordance with the HLA OMT.

2. In a federation, all simulation-associated object instance representations shall be in thefederates, not in the runtime infrastructure.

3. During a federation execution, all exchange of FOM data among federates shall occur via the RTI.

4. During a federation execution, joined fede-rates shall interact with the RTI in accor-dance with the HLA interface specification.

5. During a federation execution, an instance attribute shall be owned by at most one joined federate at any given time.

Rules for federates:

6. Federates shall have an HLA SOM, docu--mented in accordance with the HLA OMT.

7. Federates shall be able to update and/or reflect any instance attributes and send and/or receive interactions, as specified in their SOMs.

8. Federates shall be able to transfer and/or accept ownership of instance attributes dynamically during a federation execution, as specified in their SOMs.

9. Federates shall be able to vary the conditions under which they provide updates of instanceattributes, as specified in their SOMs.

10. Federates shall be able to manage local timein a way that will allow them to coordinate data exchange with other members of a federation.

2.2 HLA Federate Interface Specification

The HLA Federate Interface Specification describesthe services which federates have to use for communi-cating with other federates via a runtime infrastructure(RTI). The interface specification describes which ser-vices can be used by a federate and which services ithas to provide [12].

This bi-directional character of the interface is encapsu-lated into an ambassador paradigm. A federate commu-nicates with the RTI using its RTI ambassador. Conver-sely, the RTI communicates with a federate via its fede-rate ambassador. From the federate programmer's pointof view, these ambassadors are objects and the commu-nication among the participants is performed by callingmethods of these objects. Thus, the services defined inthe interface specification are either methods of the RTIambassador or of the federate ambassador.

+++ HLA - High Level Architecture for Modelling and Simulation ++SN

E 16/2, September 2006

7

Operating System LevelOperating System Level

HLA Runtime Infrastructure (RTIExec) FedEx-Management, Naming Service etc.HLA Runtime Infrastructure (RTIExec) FedEx-Management, Naming Service etc.

NetworkNetwork

HLA InterfaceHLA Interface

Federate AFederate Ann

HLA InterfaceHLA Interface

Federate AFederate A11

Federation „A“Federation „A“

......FederationFederation

Execution (FedEx) „A“Execution (FedEx) „A“

(RTI of the Defense Modeling & Simulation Office)(RTI of the Defense Modeling & Simulation Office)

Figure 2: Functional view of a distributedsimulation under HLA.

The interface specification defines six categories ofservices, which will be briefly described in the fol-lowing sections. A special advantage of HLA com-pared to other technologies are the time managementand the data distribution management services.

The time management services provide a mechanismfor coordinating simulation clocks of simulationsusing a wide variety of time advance mechanisms. Incomparison with other technologies, where time man-agement/synchronization is only available to a certaintype of simulation, HLA provides a general solutionfor all types of simulations.

The services provided in the data distribution categoryprovide new mechanisms for efficiently transferringdata among certain federates and for reducing theamount of data transferred. They are special in thatregard, in that previous technologies (like DIS) are usu-ally based on broadcast principles for distributing data.

Federation Management

The main focus of the services in the FederationManagement service group is the coordination of fed-eration-wide activities during a federation execution.They are used by federates to initiate, join, resign, andmanage a federation execution.

Interface services include:

- Create/Destroy Federation Execution: Theseservice are used to create and destroy federation exe-cution. Usually the first federate joining a federationexecution has the task of creating it. The last federateleaving a federation execution commonly destroys it.

- Join/Resign Federation Execution: Theseservices are used by federates to join a federation exe-cution and to resign from it once the federate has com-pleted its tasks.

- Services to save and restore federation exe-cutions: These services can be used to save and re-store the state of the federation. It should be noted thatthese service only coordinate the save/restore process.The internal state saving mechanisms have to beimplemented by the federates themselves.

Declaration Management

Federates shall use declaration management ser-vicesto declare their intention to generate and receive infor-mation. A federate shall invoke appropriate decla-ration management services before it can register ordiscover object instances, update or reflect instanceattribute values, and send or receive interactions.

With that, declaration management could also be seenas an ‘interest management’. Federates specify, whichdata types they would like to send or receive. Thepublishing and subscribing of data types (object andinteraction classes with their attributes and parame-ters) has to be performed in accordance with theSOMs and the FOM. Although declarations can bechanged dynamically during a federation execution,the declaration management belongs to the initializa-tion phase of a federation.

Interface services include:- Publish Object Class Attributes/InteractionClass: These services are used to announce that a fed-erate intends to generate the specified object and inter-action classes ‘later on’ during a federation execution.- Subscribe Object Class Attributes/ InteractionClass: These services are used to announce that afederate is interested in the specified object and inter-action classes and would like to receive infor-mationabout these classes from now on.- Start (Stop) Registration For Object Class/Turn Interactions On (Off): Using these callback func-tions to the federate, the RTI can inform a federatewhether other federates are interested in the objectclasses and interactions it has published. These servi-ces implement the so-called ‘advisory switches’ whichinform federates of the relevance of their publications.Federates can chose to ignore these switches and regi-ster object instances/ send interactions regardless ofwhether other federates are interested.

Figure 3 gives an example of services that two federatesmight use to manage their subscription and publications.

Object Management

This group of the interface specification provides servi-ces for the registration, modification, and deletion ofobject instances and the sending and receiving of inter-actions. The services of this group provide the necessaryfunctionality for all data exchange among federates.

++ HLA - High Level Architecture for Modelling and Simulation +++SN

E 16

/2,

Sept

embe

r 20

06

8

Interface

Runtime Infrastructure

Federation Management DeclarationDeclaration ManagementManagement

Object Management Ownership Management

Time Management Data Distribution Management

Federate A

intends to generate data

and receive interactions

Federate B

is interested in the data

modeled by “A” and may

send interactions

- Subscribe Object Class Attributes

- Publish Interaction Class

- Publish Object Class Attributes

- Subscribe Interaction ClassInterface

Runtime Infrastructure

Federation Management DeclarationDeclaration ManagementManagement

Object Management Ownership Management

Time Management Data Distribution Management

Federate A

intends to generate data

and receive interactions

Federate B

is interested in the data

modeled by “A” and may

send interactions

- Subscribe Object Class Attributes

- Publish Interaction Class

- Publish Object Class Attributes

- Subscribe Interaction Class

Figure 3: Declaration management (adopted from [9])

RTI services include:

- Register Object Instance/Discover Object In-stance: Each object that is relevant to a federation exe-cution needs to be registered with the RTI using theRegister Object Instance service. Interested federateswill be notified of the existence of such an objectinstance via the Discover Object Instance callback totheir federate ambassador.- Update/Reflect Attribute Values: After infor-ming the RTI about the existence of an object in-stance, the registering federate can start sending upda-tes for this object via the Update Attribute Values ser-vice. Interested federates will receive updates via theReflect Attribute Values callback to their federateambassador.- Send/Receive Interaction: Interactions can besent via the Send Interaction service and are receivedvia the Receive Interaction callback service.- Delete Object Instance: This service removesan object instance from a federation execution.- Change Transport and Ordering Mechanisms:Object updates and interactions are transported usingcertain transportation and ordering mechanisms whichcan be changed at runtime. Transportation typesinclude reliable and besteffort transmission, orderingmechanisms include time stamp order and receiveorder.

Figure 4 gives an example for the usage of the servi-ces introduced in this section.

Ownership Management

Ownership management can be used by federates andthe RTI to transfer ownership of attribute instancesamong federates. The ability to transfer ownership isintended to support the cooperative modeling of agiven object instance across a federation.

The services provided by this group support both pushand pull mechanisms for ownership transfer.

RTI services include:- Negotiated Attribute Ownership Divestiture/ Request Attribute Ownership Assumption: The serviceNegotiated Attribute Ownership Divestiture is inten-ded for federates that want to wishes to divest itself ofthe instance attribute (push). Request AttributeOwnership Assumption is the corresponding callbackto the federate ambassador for informing the federateabout the request.- Attribute Ownership Acquisition/ RequestAttribute Ownership Release: The service AttributeOwner-ship Acquisition is intended for federates thatwant to become owner of a certain set of attributes(pull). Request Attribute Ownership Release is thecorresponding callback to the federate ambassa-dorfor informing a remote federate about the re-quest.- Attribute Ownership Divestiture Notification/Acquisition Notification: These services inform the fed-erates about the success of their respective requests.

Figure 5 illustrates the push mechanism outlined above.

Time Management

Time management is concerned with the mechanismsused by simulations to advance through simulationtime. Time advances are coordinated by the RTI withobject management services so that information isdelivered to federates in a causally correct and or-dered fashion. HLA Time Management providesmechanisms to support all major types of regimes toadvance simula-tion time, such as (scaled) real-timeand as-fast-as-possible simulations.

An important design principle that is used to allow thisfunctionality is time management transparency. Thismeans the local time management mechanism used in acertain federate does not have to concern other federates.For instance, a federate using an event-oriented mecha-nism does not need to know whether the federate withwhich it is interacting is also using an event-orientedmechanisms, or (say) a time-stepped mechanism.

+++ HLA - High Level Architecture for Modelling and Simulation ++SN

E 16/2, September 2006

9

Interface

Runtime Infrastructure

FederationManagement Declaration Management

ObjectObject ManagementManagement Ownership ManagementTime Management Data Distribution Management

Federate A

has published an objectclass and intends to start

modeling an instance

Federate B

has subscribedto theobject class modeled by

federate “A”

1. Reserve Object InstanceName (optional)

2. Register object instance

3. Update attribute values

4. Discover object

instance

5. Reflect Attribute

Values

Interface

Runtime Infrastructure

FederationManagement Declaration Management

ObjectObject ManagementManagement Ownership ManagementTime Management Data Distribution Management

Federate A

has published an objectclass and intends to start

modeling an instance

Federate B

has subscribedto theobject class modeled by

federate “A”

1. Reserve Object InstanceName (optional)

2. Register object instance

3. Update attribute values

4. Discover object

instance

5. Reflect Attribute

Values

Interface

Runtime Infrastructure

FederationManagement DeclarationManagementObject Management OwnershipOwnership ManagementManagementTime Management Data Distribution Management

Federate A

wants to hand overownership of object

attribute(s)

Federate B

wants to adoptownership of object

attibute(s)

1. Negotiated AttributeOwnership Divestiture

3. Attribute OwnershipDivestiture Notification

2. Req. Attr. Owner-ship Assumption

3. Attr. OwnershipAcquisition Notif.

Interface

Runtime Infrastructure

FederationManagement DeclarationManagementObject Management OwnershipOwnership ManagementManagementTime Management Data Distribution Management

Federate A

wants to hand overownership of object

attribute(s)

Federate B

wants to adoptownership of object

attibute(s)

1. Negotiated AttributeOwnership Divestiture

3. Attribute OwnershipDivestiture Notification

2. Req. Attr. Owner-ship Assumption

3. Attr. OwnershipAcquisition Notif.

Figure 4: Object management (adopted from [9]). Figure 5: Ownership management (adopted from [9]).

An HLA federation may even include federates usingHLA Time Management services to co-ordinate theirtime advances, and others, that do not. In such anenvironment, the RTI must determine those federatesthat must be considered when coordinating timeadvances. Therefore HLA introduces two booleanflags that determine the federate's time managementcharacteristics. They are called time-constrained andtime-regulating flags. A time regulating federate isone that wishes send time-stamped messages to otherfederates and thus influence their time advancement.A time-constrained federate is one that wishes to beable to receive time-stamped messages, and thus sub-ordinates itself to the federation time advancement.

The HLA time management services are strongly rela-ted to the services for exchanging messages, e.g., attri-bute updates and interactions. There are two generalordering types for messages under HLA: receive-order (RO) and time-stamp-order (TSO). Receive-ordered messages are simply placed in a queue whenthey arrive, and are immediately eligible for deliveryto the federate. TSO messages are assigned a time-stamp by the sending federate, and are delivered toeach receiving federate in the order of non-decreasingtime stamps. Incoming TSO messages are placed intoa queue within the RTI, but are not eligible for deli-very to the federate until the RTI can guarantee thatthere will be no TSO messages for that federate witha smaller time stamp.

In order to allow the RTI to perform time manage-ment, a federate must use one of the following timemanagement services (as appropriate for the internaltime advance mechanism of the federate):

- Next Event Request (NER). Event driven federatesneed to process local and external events, i.e., eventsgenerated by other federates, in time-stamp-order. Thefederate time, i.e., its logical simulation time, typi-cally advances to the time stamp of each event as it isprocessed. An event driven federate will typically usethe Next Event Request service when it has completedall simulation activity at its current logical time inorder to advance to the time stamp of its next localevent.- Time Advance Request (TAR). Time step driven fede-rates make time advances in time steps with somefixed duration of simulation time. The simulator doesnot advance to the next time step until all simulationactivities within the current time step have been com-pleted. This type of federate will usually use the TimeAdvance Request service to request to advance itslogical time to the next time step.

- Flush Queue Request (FQR). FQR can be used foroptimistically synchronized federates to request the out-of-order delivery of events. HLA supports optimisticfederates while maintaining time management transpa-rency. Specifically, the HLA time management servicesdo not require all federates to support a rollback andrecovery capability even if one federate is using optimi-stic event processing. FQR is used by optimistic federa-tes to receive all buffered messages (although theremight be some messages at a later point in time whichcarry a smaller time stamp). In such a case the federatewill have to use the other important service Retract,which can be used to cancel a previously sent message.The RTI ensures that ‘optimistic’ messages are onlyreceived by optimistic federates, as long as there is apossibility of a later cancellation of that message.

Using one of these services a typical synchronizationloop of an HLA federate would work in the followingthree step order:1. Request advancement of logical time by

calling the appropriate RTI service (e.g., NextEvent, ...)

2. Receive zero or more messages from the RTI (e.g., receive Reflect Attribute Value or receive Interaction callback from the RTI)

3. Receive a Time Advance Grant callback from the RTI to indicate that the federate's logical time has been advanced.

A more detailed discussion of HLA Time Manage-ment can be found in [10].

Data Distribution Management

The data distribution management (DDM) servicesprovide a mechanism to reduce both the transmissionand the reception of irrelevant data. Whereas declara-tion management services provide information on datarelevance at the class attribute level, data distributionmanagement services add a capability to further refinethe data requirements at the instance attribute level.

This is achieved be defining multi-dimensional rou-ting spaces. The producers of data (the sending fede-rates) are expected to specify an update region associ-ated with a specific attribute update or interaction.This is the region in which the update or interaction isrelevant. Receiving federates have to specify whichregions they are interested in (subscription regions).The actual data transfer only takes place if the updateand subscription regions for a specific update or inter-action overlap (Figure 6).

The usage of DDM is optional, but provides a sophi-sticated means for the minimization of the amount oftransferred data and thus the network load.

++ HLA - High Level Architecture for Modelling and Simulation +++SN

E 16

/2,

Sept

embe

r 20

06

10

Figure 6: Data distribution management -example of routing spaces.

2.3 HLA Object Model Template Specification

The Object Model Template (OMT) defines the way inwhich federations and federates have to be documented.The HLA object models are the formal definition of thedata that is transferred between federates [13] and thusare one of the main vehicles for interoperability in HLA.While the HLA interface specification provides forthe technical interoperability between software sys-tems regardless of platform and language (the ‘trans-mission line’, the object model template (OMT) defi-nes the ‘language’ spoken over that line).

HLA applies an object oriented world view which isslightly different from the one known from the area ofobject oriented programming (OOP). In HLA, twotypes of classes exist: object classes and interactionclasses. Object classes describe the simulated entitieswith their attributes. Interaction classes describe therelationships between different object classes, i.e.,their interactions, and can have parameters associatedwith them. In contrast to OOP, HLA object models donot specify the methods of objects, since in the com-mon case the behavioral description is nothing thatneeds to be transferred between federates. It should be noted that this object oriented world viewdoes only define how federates have to representthemselves to other federates. The object orientedworld view does not dictate any internal representa-tion inside the federate, i.e., it merely defines theinterface to the outside world.

The HLA specification requires that each individual fede-rate provides a so-called simulation object model (SOM)which is produced according to the OMT. The SOM of afederate defines its modeling capabilities in terms of whatkind of data the federate is providing to other federatesand what it is expecting to receive from others.

In addition to each federate's SOM, the HLA speci-fication also requires that for each federation a so-called federation object model (FOM) is provided.

The FOM is a superset of the information from theindividual SOMs of the federates. It thus contains allthe classes defined by the individual participants ofthe federation and gives a description of all sharedinformation. The FOM can be seen as a contractamong n simulations to satisfy the objectives of a spe-cific federation.

In general, the object models under HLA describe:- The set of objects chosen to represent the real

world for a specific simulation/federation.- The attributes, associations, and interactions

of these objects.- The level of detail at which these objects

represent the real world, including spatial and temporal resolution.

Both the SOM and the FOM are based on a formatspecified in the OMT, which is a general template spe-cifying the tables that need to be documented:- Object Class Structure Table: This table liststhe namespace of all simulation/federation objectclasses and describes their class-subclass relations-hips. Thus it contains the (static) object class descrip-tions of a federate/federation and supports hierarchi-cal class structures. There is no mechanism for multi-ple inheritance.- Interaction Class Structure Table: This tabledescribes the ‘dynamics’ among objects by depictingall possible types of interactions among them. It alsosupports class-subclass relationships.- Attribute/Parameter Table: This table givesdetailed information about objects and interactions byspecifying the ‘features’ of object attributes and in-teraction parameters in a simulation/federation.- Data Type Table: This table specifies detailsof the data representation in the object model. This isesp. important since HLA allows the specification ofcomplex and enumerated datatypes.- FOM/SOM Lexicon: Each term listed in oneof the above tables (e.g., object class names) has to bedescribed in a verbal form in this part of the OMT.The FOM/SOM lexicon is essential to ensure that thesemantics of the terms used in an HLA object modelare understood and documented.

The issue of defining semantic interoperability is verydifficult to solve. For a general, non-application spe-cific architecture like HLA, it is necessary to keepapplication specific definitions separated from the ac-tual architecture definition. In its predecessor DIS thisguideline had not been taken account of, leading to amixture of network protocol and application specificdefinitions.

+++ HLA - High Level Architecture for Modelling and Simulation ++SN

E 16/2, September 2006

11

In HLA a strict separation of syntactic and semanticinteroperability has been followed. HLA provides thesyntax for interoperability. For solving the semanticinteroperability, HLA provides the framework for itsdefinition, i.e., the templates for establishing theobject models (SOM and FOM), but the task of fillingthe contents is left to the federation developers.

Since establishing FOMs and agreeing upon commondefinitions and understandings of certain terms whichmight be contained in a specific FOM is an effort andtime consuming task, the notion of reference FOMswas soon introduced. Reference FOMs are not part ofthe actual HLA definition. They are usually establis-hed by a group of people from a certain niche of thesimulation community, summarizing all the semanticdefinitions agreed upon in this group. One examplefor such a reference FOM is the Real-time PlatformReference FOM (RPR-FOM), which has been develo-ped in one of the SISO PDGs. The RPR-FOM provi-des the definitions commonly used in the real-timesimulation community.The process of developing object models is supportedby different existing tools (e.g., the Object ModelDevelopment Tool (OMDT) by AEgis, the VisualOMT by Pitch). These tools provide an intuitive userinterface for creating object models and allow the con-version between the HLA 1.3 format of the OMT andthe new XML-based IEEE 1516 representation.

3 Recent Developments

This section introduces recent developments andongoing efforts that go beyond the existing HLA stan-dard trying to improve it or to come up with alterna-tive solutions.

3.1 COTS Simulation Package Interoperability

Soon after the creation of HLA it became obvious thatits applicability would not be limited to military ap-plications. A majority of HLA's concepts could alsoform the basis for a much needed simulation interop-erability standard in the civilian simulation commu-nity, the manufacturing, logistics, and transportationindustry being example target application areas.

Since simulation models in industry are mainly de-signed and developed in commercial-off-the-shelf(COTS) simulation packages, the prerequisites in thissector are different. As HLA itself is not focused oncoupling models created in COTS simulation pack-ages, ways have been investigated to adopt HLA forthe usage with these packages [2,3,14]. Principal so-lutions have been developed for several packages,SLX being one of the first [15].

Ongoing standardization activities concentrate ofdefining standardized ways of providing HLA basedinteroperability for COTS packages. The challengehere is not in adopting HLA as such, but coming upwith an easy and standardized approach for a certainclass of simulation problems. The necessity of theseefforts is derived from the different possibilities of us-ing the HLA standard, e.g., a simple matter like entitypassing from one model to another can be solved indifferent ways: an entity being passed could be mod-eled as an HLA interaction sent from a sink in the firstmodel to a source in the second model. An equivalentsolution could model the entities as HLA object in-stances and use ownership management services topass the entities [16]. Both solutions are valid HLA-based solutions, but they are not interoperable.

The SISO PDG on Commercial Off-the-Shelf Simula-tion Package Interoperability is devoting its efforts tosolving these problems [17]. Their approach is basedon establishing so-called interoperability referencemodels (IRM). These IRMs describe different classesof commonly faced problems when adopting HLA fora COTS package and a standardized way to solvethem. It is anticipated that COTS package vendorsadopt these IRMs when creating HLA interfaces fortheir packages, thus achieving full interoperability forthe designated problem classes.

3.2 SISO Standardization Activities

SISO is devoted on continuously creating standardsand solutions for simulation interoperability issues. Asalready discussed, the HLA-Evolved PDG is in chargeof revising the HLA standard within the cyclic 5-yearreview process of IEEE. Other important PDGs arebriefly described in the following.

BOM PDG - Base Object Model Specification. BaseObject Models (BOMs) can be considered as reusablepackages of information representing independentpatterns of simulation interplay, and are intended to beused as building blocks in the development and exten-sion of simulations [18].The BOM is intended as a component-based standardfor describing a reusable piece part of a federation oran individual federate. BOMs provide developers andusers a modular approach for defining and adding newcapabilities to a federate or federation, and in quicklycomposing object models. BOM elements includeobject classes, interaction classes, patterns of inter-play, state machines, and events.SRML PDG - Simulation Reference Markup Lan-guage. SRML is an XML-based language for descri-bing and executing web-based simulation models.

++ HLA - High Level Architecture for Modelling and Simulation +++SN

E 16

/2,

Sept

embe

r 20

06

12

SRML is defined as an XML schema that adds simu-lation behavior to XML documents.

The intention of the PDG is to standardize SRML asthe interchange of self-describing simulation modelsthat include content and behavior, as well as standar-dizing the description of how that language wouldoperate in a simulator. The fundamental premise isthat an open XML-based standard language and exe-cution environment for simulations will benefit thesimulation industry in a similar way to that in whichthe standardization of HTML and the web browserhave benefited the general computing industry.

3.3 Standardization Activities outside SISO

The German Armed Forces Technical Centre forCommunications and Electronics, WTD 81, has takena very active role in the evaluation of the applicabilityof HLA and has introduced several interesting con-cepts that go beyond it.Initially, the efforts started with the sponsored de-velopment of GERTICO. GERTICO is an acronymfor ‘GErman Run-Time Infrastructure based onCOrba’. With this effort, the WTD has propagated itspreference for building HLA on top of an existingwell-known standard like CORBA.

In a related effort, the WTD has devised the conceptof pSISA. pSISA is the Proposed Standard Interfacefor Simulation Applications. Its purpose is to fosterthe reusability of the HLA interface code and to easethe implementation of HLA compliant applications.The major design goal is the complete encapsulationof the RTI in a object oriented shell. The applicationprogramming interface (API) accessible to the appli-cation is largely based on the object model to convey.As a result, the API is object oriented and can be builtby a code generator from the HLA simulation objectmodel (SOM) to provide C++ classes in one-to-onecorrespondence with the SOM object.

Simulations built on pSISA are thus expected to beindependent from the underlying communicationinfrastructure. The latter can be based on CORBA,HLA, or any other upcoming standard [19].Further discussions and standardization efforts out-side SISO are driven by several national groups out-side USA, e. g. the HLA Competence Centre in Mag-deburg, Germany with its annual HLA-Forum [20].

4 Evaluation and Summary

This section attempts to give an unbiased evalua-tion ofthe current state of HLA and its potential for the future.

4.1 Is HLA worth the effort?

An often heard opinion about HLA is that it is too com-plex to use, too heavy in its performance characteristicsand that there is too much overhead involved in using it.Admittedly, HLA with its federate interface specifi-cation is indeed one of the most complex standards outthere. Consequently, there is certainly a rather highlearning curve between getting a first glance at the stan-dard and having the first federation running.

However, with the objectives in mind that HLA wasdeveloped for, the author has the strong conviction thatit would be difficult if not impossible to devise a stan-dard with less complexity still fulfilling all require-ments HLA fulfills. The answer to the question, if it isalways HLA that is needed to network two simulatorshighly depends on the circumstances. If there is a veryhigh certainty that the two simulators must be networ-ked for a single purpose only and it is highly unlikelythat they ever be re-used again, then there are certainlysolutions for networking them with less effort and over-head. Otherwise the effort for creating a standardizedinteroperable version of both simulators with a highdegree of reusability is certainly worth it.

4.2 Will HLA ever become a mainstream technology?

Having been involved with HLA on both sides, acade-mia and industry, the author postulates the thesis thatHLA is far from becoming a mainstream standard forcivilian simulation applications. This also concurswith the observation made by Boer [14] in his PhDthesis. One main reason can certainly be seen in thedegree of simulation usage itself. Even though muchprogress has been made, simulation is still a nichetechnology not applied in day-to-day business intoday's industry.

Take the example of the automotive industry: Simula-tion has received a major push with the digital factoryinitiatives of many OEMs. Still, their efforts are mainlyfocused on the introduction of digital planning methods.Digital planning also involves more simulation than inearlier times, but it is still tackled with a monolithicapproach: All data is centrally stored in one planningdatabase. Planning and simulation is bound to the toolsof one software vendor. Interoperability between ven-dors and their (simulation) tools is not yet an issuewhich is on the demand list of the OEMs. Consideringthe increasing globalization and networking with sup-plier structures, it will become an issue rather soon.

Therefore the author has the strong believe that thereis a rather good potential for usage of HLA in civilianapplications. However, it will only become a main-

+++ HLA - High Level Architecture for Modelling and Simulation ++SN

E 16/2, September 2006

13

stream technology if the standard is incorporated intocommercial simulation systems by its vendors. This isthe prerequisite for making it a commodity techno-logy that can be used like any other plug-and-playstandard today.

4.3 Summary

Looking back at about 10 years of history, HLA cancertainly be regarded a success. It continues to be theleading simulation interoperability standard and isconstantly being maintained and improved by thecommunity itself.

HLA's open approach to define interfaces and functio-nalities of an infrastructure software rather than provi-ding a black box implementation has allowed soft-ware vendors to create their own HLA implemen-tations and become established in the distributedsimulation market.

Although HLA adoption in the non-military sector hasbeen rather cautious, good work is underway to stan-dardize user-friendly HLA-usage with COTS simu-lation packages. The adoption of the HLA standard byCOTS package vendors will be the prerequisite forcontinuing HLA's success in this community.

References

[1] T. Schulze, S. Straßburger, U. Klein: Migrationof HLA into Civil Domains: Solutions and Prototypes for Transportation Applications. In: SIMULATION, Vol. 73, No. 5, pp. 296-303, November 1999.

[2] S. Straßburger: Distributed Simulation Based on the High Level Architecture in Civilian Application Domains. Ghent: SCS-Europe BVBA, 2001. ISBN 1-565552180.

[3] M.D. Ryde, S.J.E.Taylor: Issues in Using COTS Simulation Packages for the Interopera-tion of Models. In: Proceedings of the 2003 Winter Simulation Conference, eds. S. Chick, P. J. Sánchez, D. Ferrin, D. J. Morrice, pp. 772-777. Dec. 7-10, 2003. New Orleans, USA.

[4] S. Taylor, B. Gan, S. Straßburger, A. Verbraeck: HLA-CSPIF Panel on Commercial Off-the-Shelf Distributed Simulation. In: Proceedings of the 2003 Winter Simulation Conference, eds. S. Chick, P. J. Sánchez, D. Ferrin, D. J. Morrice,pp. 881-887. December 7-10, 2003. New Orleans, USA.

[5] M. Rabe, F.-W. Jaekel: Non Military use of HLAwithin Distributed Manufacturing Scenarios. In: Proceedings Simulation und Visualisierung '01, (Eds.) T. Schulze, V. Hinz, S. Schlechtweg. Magdeburg, 22.03-23.03.

[6] S. Straßburger, G. Schmidgall, S. Haasis: Distributed Manufacturing Simulation as an

Enabling Technology for the Digital Factory.In: Journal of Advanced Manufacturing Systems (JAMS). Vol. 2, No. 1 (2003) 111-126.

[7] Pitch Technologies AB: Differences between HLA 1.3 and HLA 1516. Available online at WWW.PITCH.SE/hla/abouthla1516.asp

[8] DoD Interpretations of the IEEE 1516-2000 series of standards, IEEE Std 1516-2000, IEEE Std 1516.1-2000, and IEEE Std 1516.2-2000. HTTPS://WWW.DMSO.MIL/public/library/projects/

hla/rti/DoD_interps_1516_Release_2.doc

[9] J. Dahmann: HLA Tutorial. 1997 Spring Simulation Interoperability Workshop, Mar. 3-7, 1997, Orlando.

[10] R. M. Fujimoto: Parallel and Distributed Simulation Systems, Wiley Interscience, 2000.

[11] IEEE 1516-2000: IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules.

[12] IEEE 1516.1-2000: IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) Federate Interface Specification.

[13] IEEE 1516.2-2000: IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT)

[14] C. A. Boer: Distributed Simulation in Industry. Rotterdam: Erasmus Research Institute of Management, 2005. ISBN 90-5892-093-3.

[15] S. Straßburger, T. Schulze, U. Klein, J.O. Henriksen: Internet-based Simulation using off-the-shelf Simulation Tools and HLA. In: Proceedings of the 1998 Winter Simulation Conference, eds. D.J. Medeiros and E. Watson, 1669-1676. SCS, Washington, D.C.

[16] S. Straßburger, A. Hamm, G. Schmidgall, S. Haasis: Using HLA Ownership Management in Distributed Material Flow Simulations. In: Proceedings of the 2002 European Simulation Interoperability Work-shop. June 2002. London,

[17] SISO-Homepage of the CSPI-PDG. Available onlineat WWW.SISOSTDS.ORG/index.php?tg=articles&idx=More&article=43&topics=21

[18] BOMs Homepage. Available online at WWW.BOMS.INFO.

[19] T. Usländer, R. Herzog, K. Pixius, H.-P. Menzler:A CORBA infrastructure plugged into a German pSISA architecture. Simulation Interoperability Workshop, Fall 2000.

[20] HLA-Kompetenzzentrum Magdeburg. Available online at WWW.KOMPETENZZENTRUM-HLA.DE

Corresponding author: Steffen StraßburgerFraunhofer Institute for Factory Operation and Automation,Sandtorstrasse 22, 39106 Magdeburg, Germanysteffen.strassburger@iff.fraunhofer.de

Received: April 27,2006Accepted: May 19, 2006

++ HLA - High Level Architecture for Modelling and Simulation +++SN

E 16

/2,

Sept

embe

r 20

06

14

SNE 16/2, Septem

ber 2006

15

+++ Lookahead Computation in G-DEVS/HLA ++

Introduction

On the one hand, G-DEVS [7] lies in its ability todevelop uniform discrete event executable specifica-tions for hybrid dynamic systems with a scientificallycontrolled degree of accuracy. Hence, models of con-tinuous and discrete components can be representedwith the same formalism using only a continuous timerepresentation.On the other hand, HLA [16] allows integrating dis-tributed simulations, located on several computerswith different operating systems, into a global simula-tion. HLA-compliant distributed simulations inter-communicate by exchanging messages eventuallysynchronized.A first DEVS/HLA compliant environment was pro-posed by Zeigler et al. in [20, 21]. In this environment,distributed DEVS simulations intercommunicatethrough the interface (RTI) specified by HLA. In [14],Lake et al. have proposed a DEVS/HLA environmentimprovement by using the HLA lookahead. In [18],we have proposed a DEVS/HLA environment usingthe HLA lookahead without moving the managementof the coupling relations from the RTI level to thefederate level as in [14].

The focus of this article is to improve the DEVS/HLAenvironment proposed in [18]. For that purpose, in afirst part, we compute a lookahead depending on thecurrent state of DEVS models with lifetime functiondepending on only one state variable. It allows incre-asing the value of the HLA lookahead.Then, we propose going further in the improvement ofthe HLA lookahead computation. This computationtackles DEVS/G-DEVS models for which state lifeti-mes are functions of more than one state variable. Thislookahead computation is based on the shortest andlongest path search algorithms in a graph.

This improvement permits to compute non-zero HLAlookahead values from models with complex lifetimefunctions. This result is significant because the use ofgreatest values for the lookahead improves the per-formances of distributed simulation according to lite-rature on distributed discrete event simulation [5].This article is organized as follows. Section 1 gives abrief recall on DEVS/G-DEVS formalisms and HLAstandard. Section 2 recalls previous DEVS/HLA map-ping. Section 3 exposes the approach proposed forimproving the lookahead computation of the DEVS/G-DEVS HLA environment. Finally, we conclude bygiving some simulation results that illustrate the per-formances of the proposed algorithm.

1 Recall

1.1 Generalized Discrete Event System

Specification (G-DEVS)

Traditional discrete event abstraction (e.g. DEVS)approximates observed input-output signals as piece-wise constant trajectories. G-DEVS defines abstrac-tions of signals with piecewise polynomial trajectories([7]). Thus, G-DEVS defines coefficient-event as alist of values representing the polynomial coefficientsthat approximate the input-output trajectory. There-fore, a DEVS model is a zero order G-DEVS model(the input-output trajectories are piecewise constants).Formally, G-DEVS represents a dynamic system(DESN ) as an n order discrete event model expressedas a structure:

DESN = < XM, YM, S, δint , δext , λ, D, Coef >The following mappings are required:

XM = An+1, where A is a subset of integers or real numbers that represents external input events

YM = An+1, represents output eventsS = Q × (An+1), is the set of sequential model states

Lookahead Computation in G-DEVS/HLA Environment

Gregory Zacharewicz, Claudia Frydman, Norbert GiambiasiUniversité Paul Cézanne, Marseille, France

{gregory.zacharewicz; norbert.giambiasi; claudia.frydman}@lsis.org

In this article, we present new methods to evaluate lookahead of DEVS/G-DEVS federates participating in aHLA federation. We propose first an algorithm to compute the lookahead according to the current state of aDEVS/G-DEVS model. This solution is designed for models with lifetime function depending on one statevariable. Then, we extend this computation to models with lifetime functions defined with several state vari-ables. We use the Dijkstra graph theory search to compute the different values of state variables and a mathe-matical function analysis to determine the lookahead for the model states. Finally, we illustrate with an ex-ample how this solution extends the range of DEVS/G-DEVS models that can be involved into distributed

simulations and we present some simulation results.

++ Lookahead Computation in G-DEVS/HLA +++SN

E 16

/2,

Sept

embe

r 20

06

16

There Q is a set of state variables, and An+1 is a subsetof state variables that stores last input coefficientevent.For all total state (q, (an, an-1, ... , a0), e), with e beingelapsed time in S, 0 # e # D(S), and a continuouspolynomial input segment w : < t1, t2 > 6 x, the follo-wing functions are defined.

The internal transition function: that defines theautonomous state changes for the transient states, (i.e.states for which lifetime is a finite value):

δint (S) = δint (q, (an, an-1, ... , a0)) =Strajq,x (t1 + D (q, (an, an-1, ... , a0)), x)

with x = an tn + an-1 tn-1 + ... + a1 t+ a0, and Straj isthe model state trajectory with

w q 0 Q and w w : 6 x, Strajq,x : 6 Q

The external transition function: that defines thestate changes caused by external events:

δext (S, e, XM) = δext (q, (an, an-1, ... , a0), e, (a’n, a’n-1, ... , a’0)) = Strajq,x ((t1 + e), x’)

with Coef (x) = (an, an-1, ... , a0) and Coef (x’) = (a’n, a’n-1, ... , a’0)

Coef : function to associates n-coefficient of all con-tinuous polynomial function segments w over a timeinterval < ti, tj >, to the (n+1) constants values (an, an-1, ... , a0) such as:

w(t) = an tn + an-1 tn-1 + ... + a1 t + a0

Coef -1: the inverse function of Coef is applied totransform an output event in piecewise continuouspolynomial trajectory:

Coef -1(an, an-1, ... , a0) = an tn + an-1 tn-1 + ... + a1 t+ a0

The output function: triggered by autonomous statechanges, it produces output events:

λ(S) = λ (q, (an, an-1, ... , a0)) = (a’n, a’n-1, ... , a’0)

The function defining the lifetime of states: thatrepresents the maximum length or lifetime of a state, with Otraj is the model output trajectory:

D(S) = D (q, (an, an-1, ... , a0)) =min { e | Coef ( Otrajq,x (t1)) < >

+Coef ( Otrajq,x ((t1 + e)}

Otrajq,w : < t1, t2 > 6 Y

1.2 DEVS / G-DEVS Coupled Model

Zeigler has introduced, in [23], the concept of cou-pled model. Every basic model of a coupled modelinteracts with the other models to produce a globalbehaviour. The basic models are, either atomic mod-els, or coupled models stored in a library. The modelcoupling is done using a hierarchical approach.

A discrete event coupled model (DEVS or G-DEVS)is defined by the following structure:

MC = < X, Y, D, {Md | d 0 D}, EIC, EOC, IC, Select>

X: set of external events,Y: set of output events,D: set of components names,Md: DEVS/G-DEVS models,EIC: External Input Coupling relations,EOC: External Output Coupling relations,IC: Internal Coupling relations,Select:defines priorities between simultaneous

events intended for different components.

Note that to allow the coupling of different degreemodels ports, Giambiasi et al. have defined in [7], acoupling model component to transform the polyno-mial order of events exchanged.

1.3 DEVS / G-DEVS Simulator

The concept of abstract simulator has been proposedin [23] to define the simulation semantics of the for-malism. The architecture of the simulator is derivedfrom the hierarchical model structure.The processors involved in a hierarchical simulationare Simulators, which insures the simulation of theatomic models, Coordinators, which insures the rou-ting of messages between coupled models, and theRoot Coordinator, which insures the global manage-ment of the simulation (e.g. Figure 1.a, without con-sidering crosses out).The simulation runs by exchanging specific mes-sages (corresponding to different kind of events) be-tween the different processors.

1.4 The High Level Architecture (HLA)

The High Level Architecture (HLA) is a softwarearchitecture specification for global simulations thatcan include a variety of simulation programs imple-mented on distant computers and/or to reuse existingsimulations by interconnecting them ([6]).

Dr. Straßburger presents in this journal an overview ofthis specification ([16]).

SNE 16/2, Septem

ber 2006

17

+++ Lookahead Computation in G-DEVS/HLA ++

Implementation components

An HLA federation simulation is composed of fed-erates and a Runtime Infrastructure (RTI) ([11]).A federate is a HLA-compliant program, the code ofthat federate keeps its original features but must beextended by other functions to communicate withother members of the federation. These functions,contained in the HLA-specified class code of Feder-ateAmbassador, make interpretable by a local proc-ess the information received resulting from the federa-tion. Therefore, the federate program code must in-herit of FederateAmbassador to complete abstractmethods defined in this class used to receive informa-tion from the RTI.

The RTI supplies services required by a simulation, itroutes messages exchanged between federates. It iscomposed of two parts.

The Local RTI Components code (LRC, Figure 1b)supplies external features to the federate for using RTIcall back services such as the handle of objects and thetime management. The implementation is the classRTIAmbassador, this class is used to transform thedata coming from the federate in an intelligible formatfor the federation. The federate program calls thefunctions of RTIAmbassador to send data to the fede-ration or to ask information to the RTI. Each LRCcontains two queues, a FIFO queue and a time stampqueue to store data before delivering to the federate.

Finally, the Central RTI Component (CRC, Figure 1b)manages the federation notably by using the informa-tion supplied by the FOM [16] to define Objects andInteractions classes participating in the federation.Object class contains object-oriented data shared in thefederation that persists during the run time, Interactionclass data are just sent and received.

A federate can, through the services proposed by theRTI, ‘Publish’ and ‘Subscribe’ to a class of shared data.‘Publish’ allows to diffuse the creation of object instan-ces and the update of the attributes of these instances.‘Subscribe’ is the intention of a federate to reflect attri-butes of certain classes published by other federates.

HLA time management

In order to respect the temporal causality relations inthe simulation stated in [15], HLA [4, 5] proposes clas-sical conservative [1, 2] or optimistic [12] synchroniza-tion mechanisms. We focus in this article on conserva-tive synchronisation and event driven mechanism.

We recall here the time management notions from[9, 10, 11], implemented in the 1516 compliant RTIimplementation, that will be exploited in the follo-wing of this article:

Lookahead: Delay given by influencers federates tothe RTI. They certify to the RTI not to emit messageuntil their actual time plus their lookahead.

GALT (Greatest Available Logical Time): Timestamp, computed by the RTI, until influenced feder-ates will not receive information from the federation(i.e. minimum lookahead of its influencers federates).

NMR NextMessageRequest(t) (NMR(t)): Federatefunction to ask for grant to the RTI, to deal an eventtime stamped t. If the RTI callbacks the federate withTimeAdvanceGrant(t), this federate is sure to havereceived all events at t ’ # t and can emit events timestamped t ” > t.NMRA NextMessageRequestAvailable(t) (NMRA(t)):differs from NMR(t) in the call-back function. Time-AdvanceGrant(t) answer to NMRA(t), ensures thefederate to have received all events at t ’ < t and allowsit to emit events at t # t ”. In return, the federate is notsure to have received all events time stamped t.LITS (Least Incoming Time Stamp): Federate LITS isa lower bound until which the federate will receive nomessage, this value is calculated from its GALT andthe messages in transit not received yet by the federate(i.e. messages stored in the LRC queue).

2. Previous DEVS/HLA Mapping

2.1 Components Mapping

Zeigler et al., in [20, 21, 22], present a first integra-tion of DEVS Coordinators in a HLA-compliantarchitecture. They map local coupled models in HLAfederates whose coordinators of higher level will haveresponsibility to communicate with a Time Managerfederate. TM routes messages between distributedcoordinators. This federation of coordinators defines aglobal distributed coupled model.

2.2 Integrating Algorithms

As recalled in the previous section, deterministicdistributed simulations require synchronizationmechanisms in order to treat events in respect to cau-sality. In consequence, DEVS/HLA federates mustinclude integrating algorithms to communicate withthe RTI (i.e. in order to handle received messagesfrom the federation and to emit messages in a HLAformat).

++ Lookahead Computation in G-DEVS/HLA +++SN

E 16

/2,

Sept

embe

r 20

06

18

Zeigler et al. have proposed in [22] a first integratingalgorithm of DEVS models into a HLA-compliantenvironment. To guarantee the global synchronizationof Local Coordinators, this approach exploits conser-vative algorithm of [1,2] mechanism available in HLA[11]. In [14], Lake et al. have given a second approachfor mapping DEVS into HLA that resolves deadlockproblems encountered in the first solution. To this end,this approach notably uses the NMRA(t) service pro-posed by HLA instead of NMR(t). This two solutionsuse a zero or negligible value of HLA lookahead forevery federate ([4]).Reference [14] also introduced another approach thatuses a not negligible lookahead by globally broadca-sting event messages among federates and giving toeach federate a global view of DEVS coupling relations.So, the federates decide to treat or not an event regar-ding to their history of received events and to theirknowledge of coupling relations. This DEVS/ HLAenvironment uses a non-zero constant for the lookahead.However, some responsibilities of the RTI are transfer-red to the federates, what bypasses some RTI functions.

3 New G-DEVS/HLA Mapping

3.1 Components Mapping

We have proposed, in [18], an environment for crea-ting DEVS/G-DEVS models HLA compliant. Thisenvironment proposes two-step for distributingmodels (and simulators associated to).In the first step, the GDEVS coupled model is flat-tened. The hierarchical structure of a model is a userfacility, which is not necessary adapted to a simulationpurpose. This new simulation structure decreases thealgorithm complexity and so increases simulation per-formance regarding to the hierarchical one as stated

by Kim et al. and Glinsky et al. in [8, 13]. The flatte-ning of the structure induces eliminating the crossedout Coordinators on Figure 1a.In the second step, the flattened G-DEVS simulationstructure is split into coupled model by federate (Figu-re 1b) in order to build an HLA federation (i.e. a distri-buted G-DEVS coupled model). The environment con-forms to [22] mapping of Local Coordinator and Simu-lators into HLA federates, but does not use the TimeManager federate. It maps directly the Root Coordina-tor into the RTI. The reason of this mapping is the spe-cification of interface (RTI) proposes services thatenclose those defined in the DEVS Root Coordinator.Thus, the global distributed model (i.e. the federation)is constituted of federates intercommunicating.The G-DEVS models federates intercommunicate bypublishing/subscribing to HLA interactions that mapthe coupling relations of the global distributed cou-pled model. Th