modelica models in a distributed environment using fmi and hla971217/fulltext01.pdf · functional...

Linköping University | Department of Computer ScienceMaster thesis | Computer Science

Spring 2016

Modelica Models in a DistributedEnvironment Using FMI and HLA

Nicke Sievert

Supervisors: Lena Buffoni, Patrik SvenssonExaminer: Peter Fritzson

Linköping UniversitySE-581 83 Linköping

013-28 10 00, www.liu.se

LINKÖPING UNIVERSITY

AbstractFaculty of Engineering and Science

Department of Computer and Information Science

Master of Science

Modelica Models in a Distributed Environment Using FMI and HLA

by Nicke SIEVERT

Modelica is a domain independent modeling language allowing for component-based modeling of complex systems. Functional Mock-up Interface (FMI) defines astandardized interface for complex computer simulations. High Level Architecture(HLA) is an interoperability standard of a general purpose architecture for distributedsimulation. This thesis aims to show the possibilities of having Modelica models ina distributed environment by usage of FMI and HLA. An additional objective is toprovide a base for a possible generic solution.

iii

AcknowledgementsI would like to thank my examiner at Linköpings University, Peter Fritzson and my

supervisor Lena Buffoni. I would also like to thank Pitch Technologies and specificallymy supervisor at Pitch, Patrik Svensson. I would lastly like to thank Otto Tronarp fromWolfram Mathcore for much appreciated assistance and loan of software.

v

Contents

Abstract iii

Acknowledgements v

1 Introduction 11.1 Pitch Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Intended audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.6 Thesis overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Technologies and standards 32.1 Modelica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Functional Mockup Interface . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 FMI for Model Exchange . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 FMI for Co-simulation . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.3 Connected FMUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 High level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.1 Standard Components . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Ownership management . . . . . . . . . . . . . . . . . . . . . . . . 72.3.3 Real-time Platform-level Reference FOM . . . . . . . . . . . . . . 8

2.4 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.1 Modelica and FMI . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 HLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Method 113.1 Bouncing Ball Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Car Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Implementation 134.1 Bouncing Ball Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.2 Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.3 Tools used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.4 Structure of FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.5 Implementation of FmuFederate . . . . . . . . . . . . . . . . . . . 154.1.6 Implementation of BallFederate . . . . . . . . . . . . . . . . . . . 164.1.7 Implementation of GuiFederate . . . . . . . . . . . . . . . . . . . . 19

4.2 RPR Car case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.2 Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

vii

4.2.3 Tools used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.4 Modelica model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.5 Structure of FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.6 Implementation of FmuFederate . . . . . . . . . . . . . . . . . . . 214.2.7 Implementation of CarFederate . . . . . . . . . . . . . . . . . . . . 24

5 Results 275.1 Bouncing Ball Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Car Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2.1 Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Possible generic solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3.1 FMU as HLA object without ownership . . . . . . . . . . . . . . . 325.3.2 FMU as HLA object with ownership . . . . . . . . . . . . . . . . . 335.3.3 Generic FOM structure . . . . . . . . . . . . . . . . . . . . . . . . . 335.3.4 Introducing an abstraction layer . . . . . . . . . . . . . . . . . . . 36

6 Discussion 376.1 This thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1.1 Bouncing Ball Federation . . . . . . . . . . . . . . . . . . . . . . . 376.1.2 Car Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.1.3 Advantages and Disadvantages . . . . . . . . . . . . . . . . . . . 376.1.4 Generic solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7 Conclusions and future work 417.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

A Car Federation 43A.1 Relevant Controller Methods . . . . . . . . . . . . . . . . . . . . . . . . . 43A.2 FmuSimulation Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.3 ObjectClassStorage Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

B FMU-Federate Simulations Config 47B.1 XML file describing the simulations . . . . . . . . . . . . . . . . . . . . . 47

Bibliography 49

viii

List of Figures

2.1 FMI model exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 FMI co-simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Connected FMUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 HLA federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 RTI connection overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 Ownership example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.7 Ownership example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Bouncing Ball FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Bouncing Ball FmuFederate UML . . . . . . . . . . . . . . . . . . . . . . . 164.3 Bouncing Ball FmuFederate Flow diagram . . . . . . . . . . . . . . . . . 174.4 Bouncing Ball BallFederate UML . . . . . . . . . . . . . . . . . . . . . . . 174.5 Bouncing Ball BallFederate Flow diagram . . . . . . . . . . . . . . . . . . 184.6 Abstraction Layer Example . . . . . . . . . . . . . . . . . . . . . . . . . . 204.7 Car model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.8 Car model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.9 Car FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.10 Car FmuFederate UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.11 Car FmuFederate flow diagram . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Bouncing Ball Federation flow diagram . . . . . . . . . . . . . . . . . . . 285.2 Car on Google Earth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Car similation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4 Car Federation flow diagram . . . . . . . . . . . . . . . . . . . . . . . . . 315.5 Proposed general solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.6 Proposed generic FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.7 VariantRecord array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.8 Extension of generic FOM . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1 Step differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

ix

List of Abbreviations

HLA High Level ArchitectureFMI Functional Mock-up InterfaceFMU Functional Mock-up UnitME Model ExchangeCS Co-SimulationRPR Real-time Platform-level ReferenceDDM Data Distribution ManagementFOM Federation Object ModelOMT Object Model Template

xi

Chapter 1

Introduction

This chapter introduces the background and aim of the thesis, which has been proposedby and done at Pitch Technologies in Linköping, Sweden.

1.1 Pitch Technologies

Pitch Technologies (Pitch) is a company based in Linköping and is a subsidiary to BAESystems. They provide services and solutions that assist in development of distributedsimulations. The company has a large focus on the High Level Architecture (HLA) andis a strong advocate for it. Pitch is not bound to any particular domain and has clientsand customers that are both civilian and military.

1.2 Background

There was an expressed interest from Pitch to explore the possibilities of having Mod-elica models running in a distributed simulation environment using the High LevelArchitecture standard. The idea was that Modelica models could be included and runin a distributed simulation without developing a separate application for this. Thiswould allow for an increase of scalability and reuse of models due to the use of a in-teroperability standard for distributed simulation. This could lead to Modelica modelsbeing introduced into new domains, as well introduce a scalable and straight forwardprocess of having Modelica models simulated in a distributed fashion.

1.3 Objective

The goal of this thesis was to explore the possibilities of having Modelica models sim-ulated in a distributed simulation environment using the HLA standard. Specificallyit was to explore the opportunities of using the Functional Mock-up Interface (FMI) toachieve this. The main objective was to determine if HLA is a viable option for incor-porating Modelica models into a distributed simulation. A secondary objective wasto explore if a generic wrapper/adapter could be designed to allow for more rapidinclusions of models into an HLA environment.

1.4 Limitations

This thesis has had a focus on using the Functional Mock-up Interface in conjunctionwith HLA. While strongly connected to Modelica, the FMI in and of itself does not haveany restrictions on the modeling language the model is modeled in. However in this

1

2 Chapter 1. Introduction

thesis, all models that have been created have been Modelica models. The program-ming language used to develop the federate applications in this thesis has been Javadue to prior experience as well as a preference from Pitch. To ease the implementationphase, a library for unzipping, loading and interacting with Functional Mock-up Units(FMU) was used. The library used was JavaFMI1, which is an open-source project. Theproject was still under development during the thesis and its unfinished status wasnoticeable at times.

1.5 Intended audience

The targeted audience of this thesis work are anyone with basic experience or knowl-edge of computer simulations. This thesis does not assume prior knowledge in eitherModelica, FMI or HLA. The thesis aims to give enough of a theoretical background soanyone with a proper grasp of computer science can follow along.

1.6 Thesis overview

This report will in Chapter 2 cover the technologies, standards and tools used in thethesis. Following that the thesis will describe the method in Chapter 3 and implemen-tations in Chapter 4 and subsequent case studies that have been done in Chapter 5.Then there is discussion around the implementation strategies in this thesis as well asin related works in Chapter 6. Lastly, the conclusions and future work is in Chapter 7.

1https://bitbucket.org/siani/javafmi - Last accessed 2015-11-29.

Chapter 2

Technologies and standards

This chapter will name and explain the technologies and standards relevant to thisthesis as well as tools that have been used. Due to the thesis focus and the techniquesused, this section has a large focus on HLA and its features.

2.1 Modelica

Modelica[7] is an object oriented, multi domain modeling language for modeling com-plex systems with for example electronic, mechanical or electrical components. It is de-veloped and maintained by the non-profit Modelica Association1. Since it is a equationbased modeling language it does not work like a conventional programming language.For example, in most programming languages a statement such as:

x = a+ 3 (2.1)

will be treated as an assignment. In Modelica this would describes equality, allowingfor statements such as

x+ z = a+ 5 (2.2)

2.2 Functional Mockup Interface

The Functional Mock-up Interface2 (FMI) is a tool-independent standard for model ex-change and co-simulation of dynamic models. The standard was developed during acooperation project under the name MODELISAR. Since the end of the project it hasbeen managed and developed as a Modelica Assocation Project. A model that imple-ments the FMI standard is called a Functional Mock-up Unit (FMU). The FMU consistsof compiled C code which includes all equations used by the model. Also included inthe FMU are XML files, among them a model description that includes the definition ofall variables used in the model. This description can be used to find the variables in theFMU that are considered to be inputs and outputs. In addition the name of the variableand the type can be identified, which is of importance to the HLA-FMI mapping thatis needed for this thesis. Each variable is either "Integer", "Boolean", "String", "Enumer-ation" or "Real". Also specified is the causality of the variable, with the possibilities ofbeing, "input", "output", "start", "internal" or "none".

As of the writing of this thesis, there are two versions of FMI. FMI 1.0 and FMI 2.0,however the support for FMI 2.0 is limited.

The FMI has two interfaces specified, FMI for model exchange (ME) and FMI forco-simulation (CS).

1https://www.modelica.org/ Last accessed 2015-09-10.2https://www.fmi-standard.org/ Last accessed 15-11-24.

3

4 Chapter 2. Technologies and standards

FIGURE 2.1: An illustration of the components in a FMU following FMIfor model exchange.

FIGURE 2.2: An illustration of the components in a FMU following FMIfor co-simulation.

2.2.1 FMI for Model Exchange

FMI for ME has the intention of describing the model independently of the modelingtool and language it was originally created in. It allows for models to be utilized byother simulation environments than it might have been intended for. A FMU followingthe standard for ME does not include a solver and must be run by a tool that itself cansolve the model. An illustration of FMI for ME can be seen in 2.1.

2.2.2 FMI for Co-simulation

FMI for co-simulation has the intention of providing a interface for coupling of severalsimulation tools and models. This is done by providing a solver in the FMU, whichallows for the FMU to be run independently. It is not required to be run in a simulationenvironment. The data exchange between FMUs are restricted to discrete points intime. Between simulation of the FMU, values can be read and written. An example ofan executable running an accompanying FMU following FMI for co-simulation can beseen in Figure 2.2. The slave represents the loaded FMU and the master is the part ofthe application responsible for coordinating the simulation as well as transferring datato an from the FMU.

Chapter 2. Technologies and standards 5

FIGURE 2.3: An illustration of connected FMUs.

2.2.3 Connected FMUs

In the case of connected FMUs, the master is responsible for the master algorithm,which is what connects FMUs together and decides which runs when and also whenand how data is exchanged between them. An example of a connected FMUs can beseen in Figure 2.3. It displays FMUs being connected through inputs and outputs,which the master takes care of. In this example the master algorithm could if opti-mizing, have FMU B and C running simultaneously as they are independent of eachother.

2.3 High level architecture

High Level Architecture (HLA) is an interoperability standard of a general purpose ar-chitecture for distributed simulation. It is defined under IEEE Standard 1516 [2][4][3].HLA is popular within the military, and is for example heavily used by US DoD sim-ulations. However the architecture itself is not domain specific, in contrast to anotherstandard called Distributed Interactive Simulation[1] (DIS) which can be seen as a pre-decessor to HLA, yet it is still updated and used. Another important difference be-tween the two, and an important part of HLA is the separation of data transfer andthe information model. All exchange of data is according to the standard managed bya run-time infrastructure (RTI). HLA follows the publish-subscribe messaging pattern.In the context of HLA it means that the simulation applications inform the RTI of whatdata they want to publish/subscribe to. The simulation applications that connect tothe RTI are called federates. These come together in a distributed simulation called afederation. A federation which is running is called a federation execution. An exampleof a federation with three federates can be seen in Figure 2.4. It is common practice todraw federates in a federation has lollipops as seen in the figure. The basic terminologyof communication within a federation is:

• Object is a collection of attributes and are persistent in the federation. Theyare defined as Object Classes and can be sub-classed and instanced. Objects aresubscribed and published indirectly by Federates that subscribe/publish any at-tribute of that Object.


FIGURE 2.4: An illustration of a HLA federation.

• Attribute is a data field in an object. Attributes are what actually are transportedacross the distributed simulation. A federate subscribes to a set of attributes forany object and will receive updates on those attributes and not the whole object.

• Interaction is in contrast to the Object something that is sent once, involving noupdates. These can as well be subscribed and published, and they are sent withdata fields called parameters.

• Register is what a federate does when it creates and instance of an object class.

• Discover is what a federate does when an instance of an object class it is subscrib-ing to is registered by another federate.

In an example of a car, the car would be the object. Attributes could be position,speed, acceleration etc. An interaction in this scenario could be "Start", which wouldtrigger movement of the car, or "Collision" which would stop it.

2.3.1 Standard Components

The standard consists of three components. First there is a set of rules that the simula-tions must follow, one being that all communication must go through the RTI. Secondthere is the interface specification, which is a set of services that can be used to con-nect and exchange data within a distributed simulation with HLA. This specificationexists as both a Java and C++ interface. A RTI is expected to provide an API that iscompliant with this specification. Lastly there is the Object model template (OMT),which specifies what information is to be exchanged by simulations in the distributedsimulation.

All federates in a federation execution are connected with a common federation ob-ject model (FOM). The FOM is a specification that follows the structure of the OMTand defines the information that can be exchanged between federates within the fed-eration execution that uses it. The information specified is a set of object classes with


FIGURE 2.5: Figure displaying the connection between a RTI and a fed-erate.

associated attributes, interaction classes and its parameters. A federate supplies one ormultiple FOM modules to the RTI when connecting to or creating a federation.

Figure 2.5 shows a federate connected to a RTI via the HLA standard. The areamarked "interface" shows the part of the applications that are specified in the standard.The RTIAmbassador serves as the federates connection to the RTI and allows for a setof calls to be made from the federate. The FederateAmbassador on the other hand actsas the receiving end at the federate.

The latest version of the standard is HLA 1516-2010 (HLA Evolved). A primary fea-ture in this version is the possibility for multiple FOM modules, which adds re-usabilityto the FOM as well as allows for new FOM modules to be added to a federation afterits creation.

2.3.2 Services

HLA provides several important services that can be utilized. Among them are Own-ership management, Data distribution management (DDM) and Time management.Ownership management can be used to switch ownership of an attribute between fed-erates. Data distribution management can be used to limit the amount of data sent be-tween federates by defining specific regions to subscribe and publish to. Lastly, Timemanagement can be used to handle time in the federation and ensure that the federatesrun in a specific order.

Ownership management

Ownership management can be used by federates to transfer ownership of instanceattributes to federates other than that of the one that created the object instance. Itcan be used in a federation execution to achieve joint simulation of object instances.


FIGURE 2.6: Example of ownership transfer.

Ownership of instance attributes is initially given to the federate creating the objectinstance but can at the will of the owner be released and transferred.

Other federates in the federation can request transfer of ownership for any set ofinstance attributes. But it is up to the owning federate to decide if it should release theattributes. The owning federate also has the ability to request a transfer of ownership.Or this can be done forcefully by the owning federate and transfer the ownership ofthe attribute to the RTI until another federate takes it.

In Figure 2.6, a federate is interested in ownership of an attribute. It sends a re-quest for ownership to the RTI. The RTI then passes a request for release of ownershipto the owning federate. The owning federate responds and either releases or keepsownership. The RTI notifies the requesting federate regardless. If the owning federatereleased ownership then ownership will successfully be transferred to the requestingfederate.

In Figure 2.7 the roles are reversed, and it is the owning federate that wishes torelinquish ownership. It expresses its interest to the RTI via an ownership divestiturecall. The RTI will inform all federates which are publishing the given attributes thatownership the attributes are available for ownership.In this example this is received byanother federate named "Acquiring Federate". This federate decides it is interested inthese attributes, so it sends a request for ownership transfer. Since the current ownerhas expressed wish to release, the request is granted and ownership is transferred. TheRTI informs each federate of the successful ownership transfer.

2.3.3 Real-time Platform-level Reference FOM

The Real-time Platform-level Reference[8] (RPR) FOM is a FOM created to provide aHLA conversion for the capabilities in DIS. It is designed to support real time simula-tions of physical entities. Entities such as planes, ships, soldiers, etc.


FIGURE 2.7: Example of ownership divestiture.


2.4 Tools

Following are the tools used in the thesis work that are related to the standards men-tioned in this chapter.

2.4.1 Modelica and FMI

Tools used to create Modelica models or export/import FMUs.

• Wolfram SystemModeler is a modeling and simulation environment developedby Wolfram. Can be used to create and run models in Modelica. Alternativeapplications include for example Dymola and OpenModelica.

• JModelica is an open-source simulation environment for Modelica models thatalso offers the ability to export models as FMUs for CS, which is of importance tothis thesis work. JModelica is maintained by Modelon AB. An alternative wouldbe to use Dymola to create FMUs.

• JavaFMI is an open-source library allowing import and simulation of FMUs froma Java application. One alternative is JFMI. If not restricted to Java as in this thesis,the FMI Library would be an alternative as well.

2.4.2 HLA

Pitch has several products related to HLA, ranging from the necessary RTI to applica-tions that simply improves speed and comfort of implementation. Since the thesis wasdone at Pitch they were a natural choice.

• Pitch pRTI is a HLA Evolved compliant RTI.

• Pitch Visual OMT is an application for creation of FOM modules with a graphicaluser interface.

• Pitch Developer Studio is an application that, given a FOM can generate a suit-able object-oriented interface for HLA in either Java or C++.

• Pitch Google Earth Adapter is a federate that subscribes to the RPR FOM anddisplays the entities on Google Earth.

Chapter 3

Method

Using the technologies and standards mention in Chapter 2, the idea was to use thefeatures of HLA and FMI to design a set of federates and a federation to show viabilityof HLA for distributing simulation of FMUs. As the focus of this thesis lies on runningmodels in a distributed environment, FMI for co-simulation was deemed most relevant.Two HLA federations were to be designed and implemented. The first to provide a baseproof of concept of FMUs simulated in a distributed environment. The second was tobe designed with more care taken to de-couple it in terms of FMU and FOM. The firstfederation was to be a federation based on the Bouncing Ball model. The Bouncing Ballmodel is a commonly used model in the modeling domain. It is a simple simulation of aball being dropped and bouncing on the ground, it only simulates the height of the ball.The second federation was decided to be based on a vehicle, so it could be used by theRPR FOM and displayed using Pitch GE Adapter. Time Management is a service thatisn’t used in every federation, and when used it places restrictions and requirementson the complete federation. It was therefore decided to try and approach the problemwithout limiting the design to time managed federations. The library JavaFMI waschosen to load and provide a Java interface for loading and accessing the functionalityof the FMUs. Due to lacking functionality in the library as well as a general lack ofsupport for FMI 2.0, FMI 1.0 was the version chosen.

The implementation of the federations is discussed in Chapter 4 and the case studiesin Chapter 5.

3.1 Bouncing Ball Federation

The Bouncing Ball federation had a simple objective: To have a FMU running withina federate in a HLA federation. This would be designed and implemented, whichwas intended to provide basic experience with HLA and FMI as well as acting as abase proof-of-concept. The idea was to quickly develop federates to test FMUs in adistributed environment. To achieve this it was decided to use as much assistance aspossible from Pitch. This assistance came in the form of Visual OMT and DeveloperStudio. The first product helped create the FOM by providing a graphical interface todesign and export a FOM. The second helped create an object-oriented API to use forthe HLA connection of the federates.

3.2 Car Federation

While the Bouncing Ball federation was focused around a chosen FMU, the Car fed-eration was focused around a specific FOM. The federation was to use the RPR FOM,which would enable Pitch GE Adapter to visualize the RPR entities in Google Earth. In

11

12 Chapter 3. Method

order to get closer to understanding the possible generic solutions, the aim was to re-move dependencies on a specific FOM and FMU. This eliminated the possibility to useDeveloper Studio for the federate running the FMU, since it generates an API that isheavily coupled with the FOM it was generated from. Instead of the Developer StudioAPI, the standard HLA interface compatible API accompanying the RTI was used.

Chapter 4

Implementation

This chapter will go through the design and implementation of the federates createdfor the Bouncing Ball and Car federations.


The objective was to provide a basic proof of concept of a FMU being simulated withinHLA. Specifically for this federation, the goal was to do a joint simulation of an object.

4.1.1 Requirements

Due to its simplicity and availability, the Bouncing Ball FMU had been chosen. Sincethe FMU only simulated the height of the ball, an extension to a complete 2D sim-ulation was fitting for the joint simulation. It was also deemed to be advantageousfor validation purposes to create a GUI that could display the simulation. Thus, therequirements of the implementation boiled down to:

1. Create a 2D joint simulation of a ball. The Y coordinate of the ball should besimulated by a FMU in a federate and the X coordinate simulated in a separatefederate.

2. Create a visual representation of the simulation.

4.1.2 Design choices

To adhere to requirement 1 there had to be at least two federates. The second require-ment 2 could have been fulfilled by adding a GUI to one of the federates simulating theball. However in the spirit of distributed simulation it would be appropriate to have itin its own subscribing federate. The federates and their objectives became as follows:

• FmuFederate: A federate responsible for loading and simulating the FMU. Re-sponsible for simulation of the Y coordinate of the ball.

• BallFederate: A federate responsible for simulation of the X coordinate of theball.

• GuiFederate: A federate responsible for displaying the ball simulation in a 2Dviewport.

Given that the goal was joint simulation of the ball object, it meant that either ofthe two simulating federates would have to acquire ownership from the other. Onefederate would have to create the object and the other would acquire ownership of the

13

14 Chapter 4. Implementation

attribute it was to simulate. Since the goal of this thesis is to reach a conclusion aboutthe possibility of a generic solution, the FmuFederate should be involved as little aspossible where not necessary. The FMU simulates a height value, and such it wouldonly be responsible for the Y attribute. This meant that the BallFederate would be thefederate registering the HLA object and the FmuFederate would request ownershiptransfer for the Y coordinate attribute.

For this thesis, it was decided to not use Time Management, so there was a needfor a way to signal when and how long the FMU should be simulated. A few optionsdiscussed:

1. The first option was to have the FMU run at a statically hardcoded speed. Thisspeed would have to be used by the BallFederate in addition to the FmuFederate.

2. The second option was to have an attribute in the object corresponding to thecurrent time of the simulation. This would be updated whenever the FMU shouldsimulate further into the future.

3. The third option discussed was an extension of option 2 where the attributewould be placed in a separate object. This object would need to be mapped tothe corresponding ball instance.

Option 1 was, while the fastest solution, seen as inherently bad as would create theproblem of having a FMU possibly running the simulation faster then the rest of thefederation. Option 2 seemed like the smarter solution, however it was passed on foroption 3. While option 2 most likely would have been best for this particular design,the decision was heavily influenced by a growing design idea of a abstraction levelstructure which was to be fully tried in the Car federation. There, a separate objectclass would be created containing input, output and time attributes.

4.1.3 Tools used

Following are the tools used to create this federation.

• Pitch Developer Studio was used to generate a object-oriented HLA interface forall three federates. All federates were generated from the same FOM.

• Pitch Visual OMT was used to create the FOM modules in the federation.

4.1.4 Structure of FOM

Two object classes were created, ModelicaSimulation and Ball. The Ball object wascreated with the following attributes:

• Xpos: The attribute for the X coordinate of the ball.

• Ypos: The attribute for the Y coordinate of the ball.

• Radius: The radius of the ball.

• Vx: The velocity of the ball in the X direction.

• Vy: The velocity of the ball in the Y direction.

The ModelicaSimulation was created with the following attributes:

Chapter 4. Implementation 15

FIGURE 4.1: Screenshot of the Bouncing Ball FOM in Visual OMT.

• Name: Name of the simulation.

• Id: Id of the simulation.

• CurrentTime: The current time of the FMU simulation.

• UpcomingTime: The sought after time for the FMU simulation.

The end result of the FOM as seen in Visual OMT can be seen in Figure 4.1. Thedatatypes that can be seen in the figure follow the common practice in HLA, which is tonot use the basic datatypes directly. They are instead to be created as simple datatypesand have one of the basic datatypes as representation. In this case, the representationof the integers and floats were the 32-bit basic datatypes.

4.1.5 Implementation of FmuFederate

The FOM generated by Visual OMT as described in section 4.1.4 was used as inputto Developer Studio to create an object oriented HLA interface. It generates an in-terface with Java classes corresponding to HLA objects and attributes and allows forimplementation of listeners to ease the use of callbacks over HLA. An example of thegenerated interface in use in the FmuFederate can be seen in listing 4.1. In this exam-ple, the shown method is part of an implementation of the HlaBallManagerListener. Theresulting UML of the FmuFederate implementation can be seen in Figure 4.2.

LISTING 4.1: Listener that fires when a ball is discovered.

@Overridepublic void hlaBallDiscoveredHlaBall ball, HlaTimeStamp

timeStamp, HlaLogicalTime logicalTime) {try {

ball.setHlaBallOwnershipListener(this);ball.acquireOwnership(HlaBallAttributes.Attribute.YPOS);


FIGURE 4.2: Screenshot of the UML of the FmuFederate in the BouncingBall federation as generated by IntelliJ.

} catch (HlaInternalException | HlaNotConnectedException |HlaFomException | HlaRtiException e) {e.printStackTrace();

}}

The method in listing 4.1 is fired whenever a Ball object is registered. The FmuFed-erate will then try to acquire ownership of the Ypos attribute.

In a similar fashion, when ownership has been transferred, the ownershipAcquiredof the HlaBallOwnershipListener will be fired. When this happens the FmuFederate willregister a ModelicaSimulation object and map that instance to the ball instance andimmediately drop ownership of the upcomingTime attribute. It will then create andinclude an instance of FMUsimulation to those two. The FMUsimulation is the class thatcontains a loaded instance of the Bouncing Ball FMU and is responsible for simulationof it.

Whenever upcomingTimeUpdated of the listener HlaModelicaSimulationValueListeneris fired, the mapped FMUsimulation will be ordered to simulate. After simulation ofthe FMU is completed, it will read the height value from the FMU and update the Yposattribute in the ball instance that maps to that simulation. And flow diagram can beseen in Figure 4.3.

4.1.6 Implementation of BallFederate

As in section 4.1.5 Developer Studio was used to generate a HLA interface. The com-plete UML of the federate can be seen in Figure 4.4.


FIGURE 4.3: Flow diagram of the FmuFederate in the Bouncing Ball fed-eration.

FIGURE 4.4: Screenshot of the UML of the BallFederate in the BouncingBall federation as generated by IntelliJ.


FIGURE 4.5: Flow diagram of the BallFederate in the Bouncing Ball fed-eration.

The SimApp class will start up the federate and connect it to the HLA federation.The BallSimulator will create a thread and register a number of balls and immediatelydrop ownership of the Ypos attribute on all of them. It will then wait for any user inputbefore staring simulation of the balls. The simulation consists of a linear movementalong the X direction. The federate implements the HlaModelicaSimulationManagerLis-tener class and when hlaModelicaSimulationInitialized is fired it acquires ownership ofthe upcomingTime attribute. Since the Bouncing Ball FMU does not take in input, theBallFederate does not concern itself with mapping the Ball instances to the ModelicaS-imulation instances. As it is interested in simulating all the Balls, it only needs to storethem in a list and iteratively update the UpcomingTime attribute. A flow diagram ofthe federate can be seen in Figure 4.5. In listing 4.2 the code which updates the upcom-ingTime attribute on all simulations can be seen.

LISTING 4.2: Update of upcomingTime attribute.

for (HlaModelicaSimulation modSim : sims) {HlaModelicaSimulationUpdater modSimUpdater =

modSim.getHlaModelicaSimulationUpdater();modSimUpdater.setUpcomingTime(modSim.getCurrentTime() + 0.1f);modSimUpdater.sendUpdate();

}


4.1.7 Implementation of GuiFederate

As in both the FmuFederate and the BallFederate, Developer Studio was used to createa HLA interface. However for this federate, only the ball part of the FOM was needed.

This federate creates a canvas and draws the balls according to their Xpos and Ypos.It is done by a thread in a fixed interval. Alternatively it could draw on every attributeupdate by implementing the HlaBallValueListener. Each ball is updated roughly at thesame time, which would mean that the GUI would try to update X (number of balls)times very quickly and then wait. It was considered better practice to keep it on aseparate loop.

The drawing method can be seen in listing 4.3

LISTING 4.3: Drawing of ball objects.

public void paintComponent (Graphics g) {super.paintComponent(g);i++;Graphics2D g2 = (Graphics2D) g;

g2.setColor(new Color(0,0,0));g2.drawRect(0,0,415,800);

int i = 0;for (HlaBall ball :

hlaWorld.getHlaBallManager().getHlaBalls()){i++;if (i >= colors.size()) i = 0;g2.setColor(colors.get(i));g2.fillOval((int)ball.getXpos(), (int)ball.getYpos(),

(int)ball.getRadius(), (int)ball.getRadius());}

}

4.2 RPR Car case

The implementation of this federation had the main goal of simulating the position ofa RPR entity by usage of a FMU. The reason for usage of the RPR FOM was to allow forit to be displayed by Pitch GE Adapter, as well as the opportunity to use an industrialstandard FOM.

4.2.1 Requirements

The goal of this thesis was to reach a conclusion around possibilities of generic solu-tions. As such it was necessary to explore the standard HLA interface without the useof Developer Studio. This is necessary because Developer Studio creates an interfacethat is based and strongly connected to the FOM used to generate the code. The re-quirements of the federation came to be:

1. Have a FMU simulate the positioning of a RPR vehicle entity.

2. Implement the federate with the FMU without the use of Developer Studio. Onlyuse the standard HLA interface.


FIGURE 4.6: Illustration of of abstraction layer concept.

4.2.2 Design choices

According to requirement 1 the FMU was to be a simulation of a vehicle. The vehicle inquestion was chosen to be a car, since a model almost meeting the requirements couldbe found in the PlanarMechanics library supplied by Wolfram.

The positioning in RPR is done with geocentric coordinates, which does not alignwell with the output from the model that was to be used. This meant that it was un-likely to be able to use joint simulation and transferring ownership of the positioningattributes. It was instead necessary to make a individual HLA object for the model.To extend on this, the idea of introducing an abstraction layer to allow for connectedFMUs was conceived. For example, this would let a federate which wanted a car sim-ulated to not care about how many FMUs there are or how they are supposed to beconnected. As long as the they shared the same inputs and outputs, a setup of FMUscould effectively be changed without having to change functionality in the federatesinterested in it. An illustration of this point can be seen in Figure 4.6. In this figure,a Simulation is seen as a collection of connected FMUs and two Simulations are seen asinterchangeable if they have the same inputs and outputs.

The idea was to have the federate that loads and runs the FMUs to act as a masterfor a Simulation and either run the FMUs locally or have some or all of them distributedacross a HLA federation as well. In this federation, it meant that a CarSimulation ob-ject would be designed, which would be the object seen and used by the whole federa-tion. Model objects, which would represent the FMUs within a Simulation of connectedFMUs were designed as well. However in this federation the FMUs were only runlocally.

The federates that were to be designed and implemented were:

• FmuFederate: This federate is responsible for loading and simulating the FMUs.

• CarFederate: This federate is responsible for mapping the FMU object to the RPRvehicle entity.


4.2.3 Tools used

Following are the tools used to create this federation.

• Pitch Developer Studio was used to generate a object-oriented HLA interface forthe CarFederate.

• Pitch Visual OMT was used to created the FMI FOM module.

• Wolfram SystemModeler was used in conjunction with the PlanarMechanics li-brary to create the car model.

• JModelica was used to generate a FMU for CS from the Modelica model.

4.2.4 Modelica model

The car model was created in Modelica in Wolfram SystemModeler with the use ofPlanarMechanics library. It was modelled with the following inputs and outputs:

• ForwardTorque (Input): The torque applied to make the car move forward.

• SteeringTorque (Input): The torque applied to make the car steer left or right.

• X position (Output): The X coordinate of one of the bodies in the model.

• Y position (Output): The Y coordinate of one of the bodies in the model.

The end result as seen in SystemModeler can be seen in Figure 4.7. To illustrate theidea of connected FMUs, a simple model was added that would take input and modifyit by adding it with a pulse. The intention being that the input to the ForwardTorque inCar model would first pass through this model. A screenshot of the model can be seenin Figure 4.8.

4.2.5 Structure of FOM

As the federation was to be using the RPR FOM, it would have to be part of the federa-tion. Since there was to be no joint simulation in this federation as explained in section4.2.2, a new FOM module would be created. The module can be seen in Figure 4.9.

CarSimulation was the object containing the attributes for all inputs and outputs ofthe car. As it is a subclass to FmiBaseSimulation it also has the attribute UpcomingTimewhich serves the same purpose as in the Bouncing Ball Federation. The FmiBaseModeland subclass CarModel serves as representations of the FMUs and actual input andoutput values from them. In the initial case only the one FMU was used so they lookidentical. However, if the model were to be split or one to be added, there would beone subclass of FmiBaseModel for each FMU.

4.2.6 Implementation of FmuFederate

The FmuFederate in the car federation is based on the standard HLA interface insteadof a generated Developer Studio API. This meant extra work and code to piece it to-gether. The relevant part of the UML can be seen in Figure 4.10. The federate wasdesigned to be as independent of the FOM as possible while still maintaining a fast im-plementation speed. The idea was to create code that could be swapped out for input


FIGURE 4.7: Car model in SystemModeler.


FIGURE 4.8: Simple pulse addition model in SystemModeler.

FIGURE 4.9: FOM of Car in Visual OMT.


FIGURE 4.10: Screenshot of UML of FmuFederate in the Car Federationgenerated by IntelliJ.

files. The two classes ObjectClassStorage and FmuSimulation as found in Appendix A,are those that need to be modified to change the FMUs used and how they connect toHLA attributes. ObjectClassStorage defines the name of the HLA object the attributesof that object that is to be subscribed to or published. The FmuSimulation on the otherhand defines in its creation and initialization the connection between HLA and theFMU as well as which FMU to load locally.

The federate starts off by connecting to the federation, subscribing and publishingas described in the ObjectClassStorage class. Whenever it discovers a CarSimulationobject it runs the acquireAttributes method. This will try to get ownership of all theattributes that it publishes of that object, which corresponds to the outputs of the simu-lation. Whenever values of the CarSimulation object are updated, the reflectAttribute-Values is fired. This will decode the attributes to values and set the values in the FMUaccording to the connections set in the FmuSimulation class. If UpcomingTime was up-dated, the FMU will be run and update the output attributes with the new values. Aflow diagram of the federate can be seen in Figure 4.11.

4.2.7 Implementation of CarFederate

The CarFederate used a generated API from Developer Studio based on both the cre-ated FOM module mentioned in section 4.2.5 as well as the RPR FOM. The federatestarts by creating a number of RPR entities and the associated CarSimulations. It then


FIGURE 4.11: Flow diagram of the FmuFederate in the Car federation.


adds HlaCarSimulationValueListener to the CarSimulations that updates the RPR posi-tioning whenever the CarSimulation gets updated values. As in the BallFederate, therequest for updated simulation is done by updating the upcomingTime attribute on theCarSimulation object.

LISTING 4.4: .

private static WorldLocationStruct getWorldLocationStruct(doublelatDeg, double lonDeg, double alt){GeodeticLocation geodeticLocation =

GeodeticLocation.createGeodeticLocation(latDeg * Math.PI /180.0,

lonDeg * Math.PI / 180.0, alt);WorldLocation xyz =

GeodeticLocation.createWorldLocation(geodeticLocation);return WorldLocationStruct.create(xyz.getX(), xyz.getY(),

xyz.getZ());}

An example of the conversion between latitude/longitude to the WorldLocation-Struct that RPR uses can be seen in listing 4.4.

Chapter 5

Results

This chapter will go through the implemented federations and study the structure andlife cycle of the federations.


The Bouncing Ball federation consists of three federates, all designed and implementedduring and for this thesis. They hold the same naming convention as in the Implemen-tation chapter.

• FmuFederate: A federate responsible for loading and simulating the FMU. Re-sponsible for simulation of the Y coordinate of the ball.

• BallFederate: A federate responsible for simulation of the X coordinate of theball.

• GuiFederate: A federate responsible for displaying the ball simulation in a 2Dviewport.

The federates use ownership management to allow for joint simulation of an objectinstance, specifically an instance of the HLA object class Ball. The ownership of theattribute corresponding to the Y-coordinate of the ball was held by the FmuFederatewhile the same for the X-coordinate was held by the registering BallFederate.

5.1.1 Life Cycle

When the BallFederate is interested in creating a ball simulation it registers a localinstance of the Ball. When the FmuFederate discovers the instance, it will request own-ership over the y-attribute of that instance. The request is accepted by the BallFederateby releasing its ownership over the Ypos attribute and thereby completing the transferof ownership. The successful ownership transfer will put the FmuFederate in the statewhere it is ready to simulate with the corresponding FMU. Whenever the BallFeder-ate is interested in an updated y-attribute, it will update the UpcomingTime attribute.This will trigger the FmuFederate to step the FMU to match the new value of the Up-comingTime attribute. The FMU will simulate and update its variables to new values,from which the height value will be read. This value will be used to update the Yposattribute on the Ball. To illustrate join simulation of an object, the Xpos attribute of Ballis simulated by the BallFederate by giving it a constant speed.

The GuiFederate is subscribing to the Xpos and Ypos attributes of Ball and drawsthe balls accordingly every tick of a static local clock.

27

28 Chapter 5. Results

FIGURE 5.1: Flow diagram of the Bouncing Ball federation.

A flow diagram of the federation can be seen in Figure 5.1. The GuiFederate isexcluded from this as its only function is subscribing and drawing the balls with itsvalues.

5.2 Car Federation

The Car federation consists of three federates. Two were designed and implementedduring and for this thesis while the third is Pitch GE Adapter. For the first two federatesthe same naming convention as in the Implementation chapter is applied.

• FmuFederate: This federate is responsible for loading and simulating the FMUs.

• CarFederate: This federate is responsible for mapping the CarSimulation objectto the RPR vehicle entity.

• GE Adapter refers to Pitch GE Adapter. It displays all RPR entities in the federa-tion in a Google Earth instance.

Chapter 5. Results 29

FIGURE 5.2: Car displayed in Google Earth.

5.2.1 Life Cycle

The CarFederate starts by registering a number of the CarSimulation instances. TheFmuFederate discovers the CarSimulations and requests ownership over the outputattributes, which in this case is the X and Y position of the car. The CarSimulationinstance is mapped to a FMU in the FmuFederate. When ownership of the attributesis successfully transferred the initialization is done. Whenever the CarFederate up-dates the input values, which are the torques for moving forward and steering, theFmuFederate will update the values in the FMU accordingly. If the CarFederate wishesto further the simulation of the car it will update the UpcomingTime attribute. Whenit is updated, the FmuFederate will simulate the FMU enough to match the time givenin UpcomingTime. It will then update the output attributes of the CarSimulation thatare mapped to the FMU outputs.

The CarFederate then converts the X and Y position of the car to geocentric coordi-nates which are disproportionate and in no way physically accurate. It does howeverserve the purpose of visually demonstrating the federation in action in the GE Adapteras seen in Figure 5.2. To compare, the simulation done in SystemModeler displayed inFigure 5.3 was used. A flow diagram of the federation can be seen in Figure 5.4. TheGE Adapter is not included as it only subscribes to the RPR entities.


FIGURE 5.3: Simulation of car in SystemModeler.


FIGURE 5.4: Flow diagram of the Car federation.


5.3 Possible generic solutions

This section explores several ideas behind design of a generic solution for loading andrunning FMUs with HLA.

5.3.1 FMU as HLA object without ownership

This section will describe a proposed design for a generic solution. It will initially notuse ownership management, but the idea of using it will be explored in later sections.

The design would focus on generating a FOM module from the FMU. The modulewould contain two separate HLA objects. One with attributes corresponding to theinputs of the FMU and vice versa for the outputs.

The important parts of this solution can be explained in four stages. FOM gener-ation, which must be done before the federation is to be run. Initialization is whenthe FMU-Federate starts. Discovery is when the FMU-Federate discovers a relevantobject instance. Update is when the attributes subscribed to by the FMU-Federate areupdated.

• FOM Generation Given a FMU, the model description can be read to determinewhat inputs and outputs that exist for that FMU. The idea is to search through allvariables listed in the FMU and look for those stated to be inputs or outputs, thenames of these should be stored and given as attributes in the FOM module. Theinputs should be added to a object class and the outputs to another object class.For this explanation, they will be referred to as FMUInput and FMUOutput. Themapping should be done as follows:

1. For every input and output an attribute is created.

2. The name from the FMU is mapped to the attribute name. HLA does notallow for all characters that FMI does, so the attribute name might need tobe changed. One example is the parenthesis character ’(’, which seems tobe a common occurrence in modeling languages and thus in the FMUs. ncase names are changed, it is important for the FMU-Federate to know howto map HLA attributes to FMU variables and vice versa so this informationneeds to be saved and passed to the application when run.

3. The variable type needs to be mapped from FMI to HLA. There are basicdatatypes in HLA that correspond to all datatypes in FMI. It is however rec-ommended to follow best practice and introduce simple datatypes of the ba-sic datatypes. These can be predefined. An example would be ’FMIfloat32’created with the representation ’HLAfloat32BE’.

• Initialization The FMU-Federate would on start connect to a federation and in-form the RTI of subscription to the objects and attributes that correspond to theFMUs inputs. In addition it would publish the objects and attributes which cor-responds to the FMUs outputs.

• Discovery Whenever a FMUInput object instance is discovered by the FMU-Federate it would register an instance of FMUOutput. An identifier would needto be set so the two objects can be connected by other federates. This would bedone by copying a identifier attribute on the FMUInput onto the identifier at-tribute of the FMUOutput. The FMU-Federate would then create and initialize


FIGURE 5.5: Illustration of a proposed general solution.

an instance of the FMU and map it locally to the two HLA objects. The FMUInputattributes to the inputs of the FMU and the FMUOutput attributes to the outputsof the FMU.

• Update Whenever the FMUInput values are updated the corresponding valuesare saved locally by the FMU-Federate. Whenever the value of the time attributeis updated, the FMU-Federate would update the values of the FMU with thoseof the FMUInput instance, simulate the FMU according to the updated time at-tribute and finally read the values and update the FMUOutput attributes.

An illustration of the proposed design can be seen in Figure 5.5.

5.3.2 FMU as HLA object with ownership

The solution proposed in section 5.3.1 can be extended to include the use of OwnershipManagement. This would result in an arguably better FOM structure, where a FMUwould be mapped to a single HLA object class, instead of two. To achieve this, thetwo HLA object classes should be combined into a single object class, FMUCombined.Whenever the FMU-Federate would discover an instance of FMUCombined, it shouldacquire the ownership of the attributes that correspond to those from the FMUOutput.The federates would now be subscribing and publishing to the same attributes, butin one object instead of two. This would mean most everything would function as insection 5.3.1, except there is no need to map the two HLA objects to each other.

5.3.3 Generic FOM structure

All work done in this thesis, and the proposed solutions in sections 5.3.1 and 5.3.2have been on the premise of a FOM generated or created in advance. While this hasthe advantage of providing a clear structure of the objects in the federation, it meansthat every federate must at least receive the FOM module before interacting with theFMU-Federate.

However, if a generic FOM could be designed, this would no longer be necessary.A suggestion of such a FOM can be seen in Figure 5.6 and Figure 5.7. The figuresworks under the premise of the use of ownership as described in section 5.3.2. It couldhowever work in a similar fashion to section 5.3.1 if that was of preference. Figure 5.6shows a HLA object, with four attributes.


FIGURE 5.6: Illustration of a proposed generic FOM module.

FIGURE 5.7: Illustration the VariantRecord structure.


FIGURE 5.8: Illustration of an extension of the generic FOM availableFMUs.

• UpcomingTime Is consistent with the attributes usage in the rest of this thesis. Itis used to trigger the FMU-Federate to run its FMU.

• Name The name of the FMU to be run, this would most likely be a name that ismapped to a path to that particular FMU.

• Inputs A dynamic array of VariantRecord. An illustration of the structure can beseen in Figure 5.6. The VariantRecord consists of a discriminant, which is repre-sented as a enumeration. This enumeration will decide on which FixedRecord isoccupying that spot in the array. This is important since there is no knowledge ofwhat type the inputs and outputs will be of, as it depends on the FMU that theobject is currently representing.

• Outpus The same structure as the Inputs attribute.

This would allow the FMU-Federate to add a new possible FMU locally and otherfederates would, without the generation or extension of a FOM have the possibility torun the FMUs. While advantageous in that aspect, without a FOM or configurationfile, the other federates would not know of the inputs, outputs or even structure of theFMU. This means that it would rely heavily on user input. To alleviate this, the FOMcould be extended to include information about available FMUs. An example of thiscan be seen in Figure 5.8.

In this figure, the object is meant to describe an available FMU. The object class hasthree attributes.

• Name Name of the FMU.

• Inputs A dynamic array of fixed records. Each fixed record containing the nameof and type of attribute.

• Outputs The same structure as the Inputs attribute.


It is likely to have other attributes such as a description of the FMU, inputs andoutputs. The mentioned attributes are however the most important ones. This ob-ject would be registered by the FMU-Federate after joining the federation. One objectwould be registered for each available FMU. Another possibility would be to create anInteraction class to send out this information on request.

A solution like this, while giving extreme freedom, would likely be very error proneand as such would require a lot of care when designing and implementing especiallythe FMU-Federate but also other federates.

5.3.4 Introducing an abstraction layer

All proposed generic solutions have been designed to allow for single FMUs to bemapped to HLA objects. In a scenario where several FMUs are to be connected, neitherof these solutions could on their own act as a master. Another federate would have tocreate each FMU object and serve as master by passing the inputs and outputs betweenthem. All solutions mentioned so far can be extended to allow the FMU-Federate to actas a master. The idea is the one explained in Chapter 4 and used in the Car Federation.

Objects in the FOM would be separated into two categories, Simulations and Mod-els. The Simulation objects would be the abstraction, the object class that is exposed tothe whole federation. The Model objects would be the direct HLA representation of theFMUs, as they have been in this section. The idea is that a Simulation can be seen asa network of connected FMUs, which needs to be predetermined and accessible by theFMU-Federate, an proposed structure can be seen in Appendix B. When discoveringa Simulation, the FMU-Federate would create the needed FMUs. This would be doneeither locally, or by registering the Model corresponding to that FMU. By doing this, allFMUs would not have to exist on the same hardware. Since the Models would not beexposed to the rest of the federation, these could be run on a separate federation. TheFMU-Federate could be joined as a federate in two federations, one with the Simula-tions and one with only Models. This could lighten the load on the RTI in cases wheremany FMUs are to be run.

Chapter 6

Discussion

This chapter contains discussion of the designs used in this thesis as well as providesseveral ideas on how to design a generic solution for the problem.

6.1 This thesis

This section mentions the implementations done in this thesis and discuss observationsdone of the chosen designs.

6.1.1 Bouncing Ball Federation

The Bouncing Ball federation was designed with the intention that a FMU should beable to act in a distributed simulation by joint simulation of an object. Specifically,in this case it was that the FMU was in charge of simulating the Y-coordinate of abouncing ball, while another federate would be simulating the X-coordinate of the ball.To achieve this, ownership management was used to make sure that the correct federatehad control over the attributes intended for it. In this case, they together could simulatethe movement of a falling ball in a two-dimensional world.

6.1.2 Car Federation

With the car federation, there was a problem with the approach taken in the BouncingBall federation. Given the way that RPR handles positioning and most importantly,that it is working in three dimensions made it difficult to achieve a joint simulation ofa RPR entity. A car model allowing for simulation within all three dimensions wouldhave to be made or retrieved. This was considered outside the scope of the project, andso a two dimensional model was designed and exported as FMU. The output from thisFMU would have to be mapped to the positioning system used in RPR. In addition tothis problem, it was also discussed that it might be relevant to be able to swap out asingle car FMU for multiple connected FMUs that simulate a car together. Here theidea of introducing a layer of abstraction came into discussion and was added to thedesign of the federation.

6.1.3 Advantages and Disadvantages

As the Ball object in the Bouncing Ball is jointly simulated by two federates, any sub-scribing federate will receive data directly from each federate. Provided that the twofederates have similar limitations in terms of latency, the overhead can be seen as mi-nor. The only difference to the attributes being updated by the same federate wouldbe that the UpcomingTime attribute must be updated first. Since the FMU is directly

37

38 Chapter 6. Discussion

FIGURE 6.1: Illustration of the amount of steps required in each federa-tion.

mapped to an attribute, there is not any need for conversion. The raw output of theFMU must adhere to the requirements of the HLA attribute.

In the Car federation, this was not possible. The positioning given by the FMU wasnot compatible with that of the RPR FOM. This meant an extra step was introduced,and with that extra latency. An illustration of the difference between them can be seenin Figure 6.1.

6.1.4 Generic solutions

Several ideas for generic solution were provided in Chapter 5. Most of the suggestionsare based on the idea of taken a FMU (or several) as input and from it generating aFOM module with object classes and attributes to match the given FMU(s). This couldresult in a generic FMU-Federate that could in runtime:

1. Read a set of FMUs and generate a FOM module from it.

2. Connect to a federation with created FOM module, either as and addition to othermodules, or by itself.

3. Map instances of the HLA object classes to instances of the FMUs.

This would mean that the federate would create FMUs, take input, run and provideoutput just based on the FMU files given to the federate. The problem with this comesnot with the federate itself, but with the federation. For any specific use of a FMU,any other federate would have to receive a copy of the FOM module that was gener-ated, and be designed based on it as well. Unless the federate is a of a generic type.This means that for federations with a specific domain and purpose, a generic FMU-Federate might be redundant. However it would fit better in a federation designed torun any type of FMU, and provide simulation control from a separate federate.

Chapter 6. Discussion 39

6.2 Related works

This thesis aligns well with the goal cited in [5]. Muhammad Usman Awais et al. pro-posed to use the HLA RTI as a master for the FMUs. The end goal in mind was tobe able to provide a generic and standalone solution. Which they say would allowfor FMUs to be used as plug and play components in distributed environments usingHLA.

The proposed general solution in section 5.3.1 is similar to the proposed design byFaruk Yılmaz et al.[9] Their solution does however use the HLA service Time Manage-ment in contrast to the time attribute proposed in this thesis.

Muhammad Usman Awais et al. discuss in their paper[6] the problems of coupledsimulation components, as for example a series of connected FMUs. They propose analgorithm that could solve this problem, which could be of use in the design proposedin section 5.3.4.

Chapter 7

Conclusions and future work

7.1 Conclusions

This thesis has been focused on trying to connect Modelica models to a distributedsimulation using HLA. It has been shown that it can be done by creating a standaloneunit of the model following the FMI standard. This is something that can be doneby several applications in existence, for example JModelica which is what has beenused in this thesis. These units are then run from a federate that acts as a wrapperbetween the FMU and the HLA environment. Possibilities of FOM structure and theuse of the Ownership Management services have been discussed. A generic solutionhas been proposed and discussed and several ideas of extending the solution has beenmentioned.

7.2 Future work

Future work on this topic should have the short term goal of designing and imple-menting a generic solution for loading and connecting FMUs to a HLA network. Adesign based on the design proposed in this thesis should in longer term also considerTime Management. As mentioned in this thesis, Time Management is not a necessity inHLA and forcing it upon a federation can have a negative effect. However, includingthe possibility of Time Management into a generic FMU-Federate can greatly improvethe usage in federations where Time Management is sought after. In addition to this,it would also be a good idea to look into Data Distribution Management. DDM canbe beneficial when it is of interest to reduce between federates. An example would beif there are several federates interested in different amounts of FMUs. Given that theFMUs are of the same type and represented by the same HLA object, updates on theattributes will be received by all subscribing federates. DDM can be used to limit this,so that they receive updates only on the instances they are interested in.

41

Appendix A

Car Federation

A.1 Relevant Controller Methods

LISTING A.1: .

private void acquireAttributes(ObjectInstanceHandle instanceHandle){

System.err.println("Trying to acquire...");

ObjectClassPSmodel objectClassPSmodel =storage.getObjectClass();

ObjectClassHandle classHandle =rtiDispatcher.tryGetObjectClassHandle(objectClassPSmodel.getName());

AttributeHandleSet attributeHandleSet =rtiDispatcher.tryGetAttributeHandleSet();

for (String str : objectClassPSmodel.getPublishTo()){attributeHandleSet.add(rtiDispatcher.tryGetAttributeHandle(classHandle,

str));}

rtiDispatcher.tryAcquire(instanceHandle, attributeHandleSet);}

LISTING A.2: .

@Overridepublic synchronized void

reflectAttributeValues(ObjectInstanceHandle theObject,AttributeHandleValueMap theAttributes, byte[] userSuppliedTag,OrderType sentOrdering, TransportationTypeHandle theTransport,SupplementalReflectInfo reflectInfo) throwsFederateInternalError {

ObjectClassPSmodel objectClassPSmodel =storage.getObjectClass();

ObjectClassHandle classHandle =rtiDispatcher.tryGetObjectClassHandle(objectClassPSmodel.getName());

for (String str : objectClassPSmodel.getSubscribeTo()){AttributeHandle attributeHandle =

rtiDispatcher.tryGetAttributeHandle(classHandle, str);byte[] bytes = theAttributes.get(attributeHandle);if (bytes != null){

HLAfloat32BE hlaFloat32BE =rtiDispatcher.getHlaFloat32BE();

43

44 Appendix A. Car Federation

try {hlaFloat32BE.decode(bytes);simulationController.updateValue(theObject, str,

hlaFloat32BE.getValue());

List<ValuePair> valueList =simulationController.simulate(theObject);

AttributeHandleValueMap valueMap =rtiDispatcher.tryGetAttributeHandleValueMap(valueList.size());

for(ValuePair pair : valueList){hlaFloat32BE.setValue(pair.getValue());valueMap.put(rtiDispatcher.tryGetAttributeHandle(classHandle,

pair.getName()), hlaFloat32BE.toByteArray());}

rtiDispatcher.tryUpdateValues(theObject, valueMap);

} catch (DecoderException e) {e.printStackTrace();

}}

}

}

A.2 FmuSimulation Class

LISTING A.3: .

public class FmuSimulation {

private Simulation sim;private FomFmuMap fomFmuMap = new FomFmuMap();private float currentTime = 0;

public FmuExSimulation(){fomFmuMap.addConnection("tau", "Input_SteeringTorque");fomFmuMap.addConnection("tau1", "Input_ForwardTorque");fomFmuMap.addConnection("body2.r[1]", "Output_Xpos");fomFmuMap.addConnection("body2.r[2]", "Output_Ypos");

}

public void init(){try{

sim = new Simulation("MyCarFixed_3.fmu");sim.init(currentTime);

}catch (Exception e){e.printStackTrace();

}}

public void updateValue(String fom, float val){

Appendix A. Car Federation 45

if (fom.equals("UpcomingTime")){sim.doStep(val - currentTime);currentTime = val;

}else{sim.writeVariable(fomFmuMap.getFmuName(fom), val);

}}

public List<ValuePair> simulate() {List<ValuePair> valueList = new ArrayList<>();

double val = (double)sim.readVariable("body2.r[1]").getValue();

ValuePair pairOne = newValuePair(fomFmuMap.getFomName("body2.r[1]"),(float)val);

double val2 = (double)sim.readVariable("body2.r[2]").getValue();

ValuePair pairTwo = newValuePair(fomFmuMap.getFomName("body2.r[2]"),(float)val2);

valueList.add(pairOne);valueList.add(pairTwo);

return valueList;}

}

A.3 ObjectClassStorage Class

LISTING A.4: .

public class ObjectClassStorage {

public ObjectClassPSmodel getObjectClass(){ObjectClassPSmodel objectClassPSmodel = new

ObjectClassPSmodel("HLAobjectRoot.FmiBaseSimulation.CarSimulation");

objectClassPSmodel.addSubscription("UpcomingTime");objectClassPSmodel.addSubscription("Input_SteeringTorque");objectClassPSmodel.addSubscription("Input_ForwardTorque");objectClassPSmodel.addPublish("CurrentTime");objectClassPSmodel.addPublish("Output_Xpos");objectClassPSmodel.addPublish("Output_Ypos");

return objectClassPSmodel;}

}

Appendix B

FMU-Federate Simulations Config

B.1 XML file describing the simulations

LISTING B.1: .

<?xml version="1.0"?><adaption>

<models><model id="m0" fmuName="fmu_path_0" fomName="fom_m_0">

<listOfModelInputs><input id="i0" fmuName="fmu_i_0" fomName="fom_i_0"/>

</listOfModelInputs><listOfModelOutput>

<output id="o0" fmuName="fmu_o_0" fomName="fom_o_0"/></listOfModelOutput>

</model>

<model id="m1" fmuName="fmu_path_1" fomName="fom_m_1"><listOfModelInputs>

<input id="i0" fmuName="fmu_i_0" fomName="fom_i_0"/></listOfModelInputs><listOfModelOutput>

<output id="o0" fmuName="fmu_o_0" fomName="fom_o_0"/></listOfModelOutput>

</model></models>

<simulations><simulation id = "s0" fomName="fom_s_0">

<listOfModels><model type="m0" id="mi0"/><model type="m1" id="mi1"/>

</listOfModels>

<listOfSimInputs><simInput fomName="fom_i_1" toModel="mi0" toInput="i0"/>

</listOfSimInputs>

<listOfSimOutputs><simOutput fomName="fom_o_1" fromModel="mi1"

fromOutput="o0"/></listOfSimOutputs>

<listOfConnectors>

47

48 Appendix B. FMU-Federate Simulations Config

<modelConnector fromModel="mi0" fromOutput="o0"toModel="mi1" toInput="i0"/>

</listOfConnectors>

</simulation></simulations>

</adaption>

Bibliography

[1] “1278.2-2015 - IEEE Standard for Distributed Interactive Simulation (DIS) – Com-munication Services and Profiles”. In: IEEE (2015). URL: http://standards.ieee.org/findstds/standard/1278.2-2015.html.

[2] “1516-2010 - IEEE Standard for Modeling and Simulation (M&S) High Level Ar-chitecture (HLA)– Framework and Rules”. In: IEEE (2010). URL: http://standards.ieee.org/findstds/standard/1516-2010.html.

[3] “1516.1-2010 - IEEE Standard for Modeling and Simulation (M&S) High Level Ar-chitecture (HLA)– Federate Interface Specification”. In: IEEE (2010). URL: http://standards.ieee.org/findstds/standard/1516.1-2010.html.

[4] “1516.2-2010 - IEEE Standard for Modeling and Simulation (M&S) High Level Ar-chitecture (HLA)– Object Model Template (OMT) Specification”. In: IEEE (2010).URL: http://standards.ieee.org/findstds/standard/1516.2-2010.html.

[5] Muhammad Usman Awais et al. “The high level architecture RTI as a master tothe functional mock-up interface components”. In: San Diego, CA: Computing,Networking and Communications (ICNC), 2013 International Conference on, Jan.2013. URL: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6504102.

[6] Muhammad Usman Awais et al. “Using the HLA for Distributed ContinuousSimulations”. In: Cardiff: Modelling and Simulation (EUROSIM), 2013 8th EU-ROSIM Congress on, Sept. 2013. URL: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7005001.

[7] Peter Fritzson. Principles of Object-Oriented Modeling and Simulation with Modelica2.1. Wiley-IEEE Press, Feb. 2004. ISBN: 0-471-471631.

[8] “SISO-STD-001.1-2015: Standard for Real-time Platform Reference Federation Ob-ject Model (RPR FOM), Version 2.0”. In: SISO (2015).

[9] Faruk Yılmaz, Umut Durak, and Koray Taylan. “Adapting Functional MockupUnit s for HLA -compliant Distributed Simulation”. In: Lund, Sweden: Proceed-ings of the 10th International ModelicaConference, Mar. 2014. URL: https://modelica.org/events/modelica2014/proceedings/html/submissions/ECP14096247_YilmazDurakTaylanOguztuzun.pdf.

49

http://standards.ieee.org/findstds/standard/1278.2-2015.html


http://standards.ieee.org/findstds/standard/1516-2010.html

http://standards.ieee.org/findstds/standard/1516-2010.html





http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6504102




https://modelica.org/events/modelica2014/proceedings/html/submissions/ECP14096247_YilmazDurakTaylanOguztuzun.pdf



50 BIBLIOGRAPHY

Linköping University Electronic Press

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – frånpubliceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skrivaut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommer-siell forskning och för undervisning. Överföring av upphovsrätten vid en senare tid-punkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräverupphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgäng-ligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i denomfattning som god sed kräver vid användning av dokumentet på ovan beskrivnasätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i så-dant sammanhang som är kränkande för upphovsmannens litterära eller konstnärligaanseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible re-placement – from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyoneto read, to download, or to print out single copies for his/hers own use and to use it un-changed for non-commercial research and educational purpose. Subsequent transfersof copyright cannot revoke this permission. All other uses of the document are condi-tional upon the consent of the copyright owner. The publisher has taken technical andadministrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentionedwhen his/her work is accessed as described above and to be protected against infringe-ment.

For additional information about the Linköping University Electronic Press and itsprocedures for publication and for assurance of document integrity, please refer to itswww home page: http://www.ep.liu.se/.

© Nicke Sievert

http://www.ep.liu.se/

http://www.ep.liu.se/

modelica models in a distributed environment using fmi and hla971217/fulltext01.pdf · functional...

Documents