co-simulation environment for modeling networked cyber-physical

Co-simulation Environment for Modeling

Networked Cyber-Physical Systems

by

Mohannad Alharthi

A thesis submitted to the

School of Computing

in conformity with the requirements for

the degree of Master of Science

Queen’s University

Kingston, Ontario, Canada

April 2014

Copyright c© Mohannad Alharthi, 2014

Abstract

Cyber-physical systems (CPSs) represent a new generation of engineered systems

that tightly integrates computations, communications (cyber) and physics. Simula-

tion plays a considerable role in validating CPSs as it substantially reduces the costs

and risks in the design-testing cycles. Reliable simulations, however, mandate realis-

tic modeling for both the cyber and the physical aspects. This is especially the case

in various networked mobile CPSs (e.g., excavation robots and vehicular networks),

where cost and risk may become substantial. Current CPS modeling tools lack com-

plete models of communication. Co-simulation attempts to overcome this limitation

by integrating multiple modeling and simulation tools to offer complete models of

all aspects of CPSs. In this thesis, we design and implement a co-simulation envi-

ronment for modeling and simulating networked CPSs. The environment is called

AcumenNS3 and it integrates Acumen, a language for modeling hybrid physical sys-

tems, with NS-3, a discrete-event network simulator. This environment allows users

to augment network simulations with physical models using an easy-to-use modeling

language. It provides a seamless integration between network and physics models by

providing mobility based on the physical simulation in addition to generic access to

the physical state. Using the AcumenNS3 environment, we demonstrate and model

example simulation scenarios of networked CPSs.

i

Acknowledgments

All praise and thanks are due to God for his blessings and giving me the strength,

health, and time to be able to produce this work.

Many thanks to my to supervisor Dr. Abd-Elhamid Taha for his support, encour-

agement, patience, guidance and knowledge which helped me greatly throughout my

research. Thanks also go to my co-supervisor Dr. Hossam Hassanien for his support,

encouragement and advice. I am extremely grateful to both of them for giving me

the opportunity and making my experience at Queen’s a very pleasant one.

I would like to thank Dr. Walid Taha and Viktor Vasilev from Halmstad University

for their help in Acumen development.

I also would like to thank the examining committee for their valuable feedback on

this thesis.

I would like also to thank my friends and lab mates in the Telecommunications

Research Lab for their friendship and support, and for being great lab mates and

friends. I would like to thank Abdulrahman Abahsain, Abdulmonem Rashwan, Sherin

Abdel Hamid, Dr. Abdallah Alma’aitah, Mohannad Alswailim, and everyone who

helped me directly or indirectly during my studies. Thanks also to the lab coordinator

Basia Palmer.

Many thanks to friends both here in Canada and those too far away back home

ii

for being great friends, keeping me company, and keeping in touch.

I would like to thank my dear family, especially my parents, who I could never be

able to thank enough for their endless support, prayers, and all that they did for me

my whole life.

iii

Table of Contents

Abstract i

Acknowledgments ii

Table of Contents iv

List of Tables vii

List of Figures viii

List of Code Listings ix

Acronyms x

Chapter 1:Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Organization of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2:Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Cyber-Physical Systems . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.1 Networked CPSs . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Modeling Challenges . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Modeling the Physical Aspects . . . . . . . . . . . . . . . . . . . . . . 112.3 Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Modeling Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 Overview of Mobility Models . . . . . . . . . . . . . . . . . . . 172.4.3 Impact of Mobility on Network Performance . . . . . . . . . . 21

iv

2.4.4 Modeling Mobility for VANETs and Networked Robotics . . . 232.5 Co-simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5.1 Co-simulation Environments . . . . . . . . . . . . . . . . . . . 272.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.7 Modeling Physical Systems and Computer

Networks in Acumen and NS-3 . . . . . . . . . . . . . . . . . . . . . 312.7.1 Acumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.7.2 Network Simulator 3 (NS-3) . . . . . . . . . . . . . . . . . . . 34

Chapter 3:The AcumenNS3 Co-simulation Environment . . . . . . 41

3.1 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2 Why Acumen and NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . 443.3 AcumenNS3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 453.4 Co-simulation Overview . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.1 Role of Acumen Models . . . . . . . . . . . . . . . . . . . . . 483.5 Operations of AcumenNS3 . . . . . . . . . . . . . . . . . . . . . . . . 49

3.5.1 Configuration and Initialization . . . . . . . . . . . . . . . . . 493.5.2 Modeling Mobility . . . . . . . . . . . . . . . . . . . . . . . . 503.5.3 Accessing the State of Physical Models . . . . . . . . . . . . . 503.5.4 AcumenNS3 Scheduler . . . . . . . . . . . . . . . . . . . . . . 52

Chapter 4:AcumenNS3 Implementation . . . . . . . . . . . . . . . . 55

4.1 Acumen in Server Mode . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 AcumenNS3 Components Implementation . . . . . . . . . . . . . . . 564.3 Acumen Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.3.1 Modeling Mobility in Acumen . . . . . . . . . . . . . . . . . . 584.4 Shared Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.5 Mobility Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.6 The Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.7 Configuration and Initialization . . . . . . . . . . . . . . . . . . . . . 61

4.7.1 The Configuration File . . . . . . . . . . . . . . . . . . . . . . 624.8 Setting up a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.8.1 Example Experiment Scenario . . . . . . . . . . . . . . . . . . 64

Chapter 5:Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2 Leader-Follower Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

v

5.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.3 Controlled Inverted Pendulum . . . . . . . . . . . . . . . . . . . . . . 79

5.3.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.4 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 6:Conclusion and Future Work . . . . . . . . . . . . . . . . 90

6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Appendix A:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

A.1 Acumen State Serialization . . . . . . . . . . . . . . . . . . . . . . . . 103A.1.1 Acumen State . . . . . . . . . . . . . . . . . . . . . . . . . . . 103A.1.2 State Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A.2 AcumenNS3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

vi

List of Tables

5.1 CPU times for the lead-follow simulations. . . . . . . . . . . . . . . . 765.2 CPU times for the lead-follow simulations with additional features. . 785.3 CPU times for the inverted pendulum simulations. . . . . . . . . . . . 86

vii

List of Figures

2.3 The movement of a group in RPGM. . . . . . . . . . . . . . . . . . . 202.4 Bouncing ball model in Acumen GUI. . . . . . . . . . . . . . . . . . . 34

3.1 AcumenNS3 client-server model. . . . . . . . . . . . . . . . . . . . . . 433.2 Architecture of the co-simulation environment. . . . . . . . . . . . . . 453.3 Architecture of the AcumenNS3 interface. . . . . . . . . . . . . . . . 473.4 Timeline of the Co-simulation. . . . . . . . . . . . . . . . . . . . . . . 48

5.1 Simulation results for lead-follow using standalone NS-3 with 0.01 ssampling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Simulation results for lead-follow using standalone NS-3 with 0.2 ssampling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3 Simulation results for lead-follow using standalone NS-3 with 1 s sam-pling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4 Simulation results for lead-follow using AcumenNS3. . . . . . . . . . 755.5 Simulation field for lead-follow with variable terrain. . . . . . . . . . . 765.6 Simulation results for lead-follow with variable terrain using AcumenNS3. 775.7 Simulation results for lead-follow with RSS and variable terrain using

AcumenNS3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.8 The inverted pendulum. . . . . . . . . . . . . . . . . . . . . . . . . . 805.9 Simulation results of the inverted pendulum with 2 ms delay (point-

to-point controller). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.10 Simulation results of the inverted pendulum with 5 ms delay (point-

to-point controller). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.11 Simulation results of the inverted pendulum with 10 ms delay (point-

to-point controller). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.12 Simulation results of the inverted pendulum using a wirelessly con-

nected controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A.1 AcumenNS3 C++ class diagram - Part 1. . . . . . . . . . . . . . . . . 107A.2 AcumenNS3 C++ class diagram - Part 2. . . . . . . . . . . . . . . . . 108

viii

List of Code Listings

2.1 Simple bouncing ball model in Acumen. . . . . . . . . . . . . . . . . 352.2 Basic NS-3 simulation script. . . . . . . . . . . . . . . . . . . . . . . . 383.1 Example of using shared variables. . . . . . . . . . . . . . . . . . . . 524.1 Modeling mobility in Acumen. . . . . . . . . . . . . . . . . . . . . . . 584.2 Using shared variables by associated nodes. . . . . . . . . . . . . . . . 594.3 Defining Acumen class with a name attribute. . . . . . . . . . . . . . 604.4 Using shared variables by instance name. . . . . . . . . . . . . . . . . 604.5 A simple Acumen model. . . . . . . . . . . . . . . . . . . . . . . . . . 654.6 The configuration file for the simple experiment. . . . . . . . . . . . . 664.7 C++ code for the NS-3 script. . . . . . . . . . . . . . . . . . . . . . . 685.1 Acumen model for lead-follow. . . . . . . . . . . . . . . . . . . . . . . 725.2 Acumen model for the inverted pendulum. . . . . . . . . . . . . . . . 83A.1 Acumen state in JSON. . . . . . . . . . . . . . . . . . . . . . . . . . 105A.2 State updates in JSON. . . . . . . . . . . . . . . . . . . . . . . . . . 106

ix

Acronyms

CPS Cyber-Physical System

NS-2 Network Simulator 2

NS-3 Network Simulator 3

MANET Mobile Ad hoc Network

I/O Input/Output

GUI Graphical User Interface

3D 3-Dimensional

OTcl Object Tool Command Language

NED Network Description

VANET Vehicular Ad hoc Network

RPGM Reference Point Group Mobility

IVC Inter-Vehicle Communication

HLA High Level Architecture

NCS Networked Control System

SANET Sensor/Actuator Network

ODE Open Dynamics Engine

MAC Medium Access Control

NIC Network Interface Controller

x

IP Internet Protocol

PCAP Packet Capture

BSD Berkley Software Distribution

JSON JavaScript Object Notation

API Application Programming Interface

CStore Canonical Store

JRE Java Runtime Environment

AODV Ad hoc On-Demand Distance Vector Routing

UDP User Datagram Protocol

RSS Received Signal Strength

PPP Point-toPoint Protocol

TCP Transmission Control Protocol

WSN Wireless Sensor Network

FMI Functional Mock-up Interface

xi

Chapter 1

Introduction

Cyber-physical systems (CPSs) represent a class of next-generation engineered sys-

tems that integrates computing, physical, and communication components. The inte-

gration of computations and communications , as the cyber components, with physical

elements such as mechanical, electronic, electromagnetic to name a few, allows for a

greater control of the physical system in addition to improved robustness, efficiency,

and autonomy. Systems with such characteristics could offer great benefits to society,

through many applications such as transportation, energy, and manufacturing.

Given the broad scope of these benefits, CPSs have been a popular field of research

in engineering and science. The interest in CPS has attracted both industry and gov-

ernment to invest in CPS research [42]. For instance, the National Science Foundation

(NSF) has been funding several CPS research projects, such as “Science of Integration

for Cyber-Physical Systems”, a collective research project between the University of

Notre Dame, Vanderbilt University, the University of Maryland and General Motors

Research [10], in addition to other projects lead by several academic institutions and

industry[9]. Such research projects have already shown progress through development

1

CHAPTER 1. INTRODUCTION 2

of innovative systems. Notable and most recent innovations include autonomous au-

tomobiles such as the one developed by researchers at CarnegieMellon University.

[53].

Building an actual CPS for experimentation and development can be an expensive

process, especially if testing entails sophisticated equipment or elaborate setups and

possibly safety hazards. For that purpose, researchers rely on building virtual models

for simulation and experimentation. Testing the CPS in this manner can provide a

great advantage for researchers as they can prototype the system and test it virtually

in order to improve the design and avoid errors [50].

Modeling CPSs can be challenging as the reliability can be dependent on the de-

tail and accuracy of models. A detailed and accurate model requires collaboration

between experts from several fields in engineering and computing. Moreover, tools

and languages are needed to model aspects from different disciplines. Currently there

are various independent tools for modeling control systems, physical systems, and

computer networks. A physical modeling tool can be used to model the physical

aspects of the system, but when it comes to networked CPSs, we do not have the

capability to model the network in the physical modeling tool. Thus, more compre-

hensive tools are needed that combine all aspects of CPSs including physics, control

and communications.

Co-simulation is a modeling and simulation technique that aims at taking ad-

vantage of available modeling tools that specialize in modeling specific parts of the

CPS by integrating multiple tools to model and simulate the complete CPS. Efforts

in co-simulation have produced tools and environments that target specific applica-

tions of CPS such as networked robotics. Such tools integrate specific independent


tools for modeling the network and physics. Some tools can derive and generate

implementation code from the simulated model.

1.1 Motivation

The motivation behind co-simulation is to address the lack of complete models for

networked CPSs, the lack of which leads to modeling difficulty using existing tools.

Most physical modeling tools rely on simplistic network models, or at best, a limited

support of the network stack, which makes such tools insufficient for networked CPS.

On the other hand, network simulators, while providing detailed network models, lack

the capability to realistically and reliably model physical phenomena such as mobility

or wave propagation in the channel. Those aspects are replaced with practical ab-

stracted models. While the channel is not addressed in this work, mobility or nodes

movement needs to be modeled more realistically, as it is more related to the physical

side of the system. For its effect on networking performance, mobility needs to be

modeled accurately by utilizing co-simulation in order to achieve reliable simulations.

Co-simulation efforts attempt to address some of these limitations. As will be

discussed in detail in Chapter 2, efforts in the literature vary in their objectives,

capabilities, and the tools integrated in terms of availability and usability.

1.2 Objective

The objective of this thesis is to present an environment that allows for physical

continuous-time or discrete models to be incorporated into network simulation. Such

an environment would allow physical phenomena to be modeled in a true physical


modeling environment without compromising accuracy by modeling the physical phe-

nomenon in the network simulator.

An advantage of this integration is more realistic modeling of mobility, as the

produced mobility behavior is the result of physics simulation, not a result of syn-

thesized or randomly generated movements. Additionally, general physical modeling

can be utilized within the network simulation in some scenarios where mobility is not

necessarily part of the simulated experiment.

Our goal is to develop a co-simulation environment that augments a mainstream

network simulator with a physical modeling language. The network simulator of

choice is the Network Simulator 3 (NS-3), and the physical modeling language is

Acumen. Section 2.7 introduces above mentioned tools in more detail.

1.3 Contribution

The contribution of this thesis is a design and implementation of a co-simulation

environment for modeling and simulating CPSs. The environment combines a physical

modeling tool and a network simulator. Acumen is used to model the physical aspects

of a system with focus on mobility, while NS-3 is used to model the cyber aspects

realized by networking capabilities. The environment is called AcumenNS3, and it is

designed to includes the following features:

• Utilizing Acumen modeling environment, an easy to learn and use language

for modeling discrete/continuous systems, along with NS-3 network simulator,

a state-of-the-art network simulator that provides models for various network

layers.


• Seamless integration between Acumen and NS-3. Users provide physical models

in Acumen, along with NS-3 C++ code for specifying the network. The Acu-

menNS3 environment automates the integration of the two simulators behind

the scenes, instantiating the required Acumen models, setting the simulation

parameters through a unified manner, and exchanging model state between the

simulators during the simulation.

• State of Acumen models are easily accessible from the C++ code of NS-3

through a set of provided functions, in addition to the concept of shared vari-

ables, which provide the ability to access/modify variables or attributes of Acu-

men model instances, in the same manner as regular variables in C++.

1.4 Organization of Thesis

In Chapter 2, we discuss several topics with respect to the motivation of the thesis. We

discuss CPSs, CPSs modeling, and mobility models. We also overview tools used for

network simulation and modeling physical systems. Then, we discuss co-simulation

and reference some related work. We also give an introduction to the tools used in

our work.

In Chapter 3, we propose our co-simulation environment AcumenNS3, and present

its design. Then, we discuss the implementation specifics and usage of the Acu-

menNS3 environment in Chapter 4.

In Chapter 5, we demonstrate some use-case scenarios to evaluate AcumenNS3.

Finally, in Chapter 6, we conclude the thesis and highlight future work directions.

Chapter 2

Background

In this chapter, we discuss several background topics related to the work presented

in this thesis. In particular, we emphasize the need for better physical modeling in

current network simulators. First, we discuss CPSs and the challenges involved in

modeling CPSs. Second, we discuss network simulation and modeling of physical

systems. Third, we review mobility models found in popular network simulators

and in the literature. We also highlight the shortcomings of such models and the

impact they have on simulation results. We also discuss mobility modeling for some

applications of CPSs. Next, we overview co-simulation as a solution aimed at better

physics/network modeling and simulation, and we look at some of the related work

in co-simulation. Lastly, we acquaint the reader with the Acumen modeling language

and the NS-3 simulator, as they represent the foundations of the work presented in

this thesis.

6

CHAPTER 2. BACKGROUND 7

2.1 Cyber-Physical Systems

A Cyber-Physical System (CPS) is a system that integrates physical processes with

computations and communications. The physical aspect represents the physical ob-

jects or phenomena which can be mechanical, chemical, or electromagnetic for ex-

ample. The cyber aspect is realized by computations which are the software that

implements the control logic and governs the system in addition to communications

which aids the control via communications channels. Thus, the term CPS describes

such integrated engineered systems where the physics and computations are tightly

dependent on each other [13].

Studying CPSs is a joint field of several disciplines in engineering and computing,

such as control systems, hybrid-systems, real-time and embedded systems, network-

ing, and software engineering [25]. Control systems represent the field concerned with

how a system can be designed so it can be regulated to achieve a desired behavior.

The regulation of the system is the task of the controller which observes the system

and adjust its state to a desired condition. The controller can be either an analog or a

digital computer. Hybrid systems are used to describe systems that are characterized

by both continuous and discrete behavior. Real-time systems is a computing field

that involves scheduling of computation tasks so the results are obtained exactly at

the time they are needed, which is crucial for implementing controllers.

CPSs can be seen as an evolution of many of the controlled systems that we ben-

efit from as a society today [25]. Examples of such systems can be found in different

areas such as transportation (aircrafts, automobiles), energy (power grids), and man-

ufacturing. Prominent examples of next-generation CPSs include innovations such as

the Segway transporter [47] (a two-wheeled, self-balancing personal vehicle shown in


Figure 2.1(a)), powered exoskeletons (powered suits that allow the person to carry

heavy loads or provide extra support for movements, such as the one from Berkeley

shown in Figure 2.1(b)) and smart or auto-driving vehicles and drones. Such systems

are characterized by being equipped with intelligent sensors, cameras and actuators

and mechanical parts that are controlled by advanced embedded computing systems

[41]. Development of CPSs that led to such promising applications was substantially

influenced by advancements in both computing and communication fields such as em-

bedded systems and sensor networks which allowed enhanced control of the physical

system.

(a) The Segway personal

transporter [47]

(b) An exoskeleton [5]

Figure 2.1: Examples of cyber physical systems.

The field of CPSs has gained a lot of interest in recent years because of its benefits

to society [42]. CPSs represent a new generation of engineered systems that are

expected to improve the quality of life by providing efficient and reliable autonomous


systems. As a result, research interest has increased in several CPS areas offering

promising innovations. Efforts in CPS research are not limited to the development of

new technologies but also, efforts in developing modeling and development tools for

such systems. The term CPSs was formed in 2006 by researchers in several engineering

disciplines, which represents the significance of this area in engineering [25].

2.1.1 Networked CPSs

CPSs can also rely on communication technologies. For instance, system monitoring

information and control signals can be sent over the network between the different

components of the system such as sensors, actuators and controllers. In other exam-

ples, systems comprised of several entities distributed in space can interact with each

other to deliver information or accomplish an assigned goal. Examples of such sys-

tems can be found in excavation robots and tele-surgery, where either an operator or

a computer can operate the system from a remote location. Other notable examples

include connected vehicles and autonomous robotics. For example, connected vehi-

cles communicate with other vehicles on the road or roadside network infrastructure

to provide information about road conditions, traffic flow, and directions [42]. Net-

work technologies such as Mobile Ad hoc Networks (MANETs) can be used in such

networked CPSs. In MANETs, a pre-existing network infrastructure is not needed,

and communication can be established directly between network entities. In such

applications, reliable communication is a critical part to the overall functioning of

the system [16].


2.1.2 Modeling Challenges

An important aspect of developing CPSs is modeling and simulation of the systems.

Modeling allows for improved design and testing which leads to reduced costs for

design and development. Engineers utilize specialized tools and languages for general

physical modeling which we review in Section 2.2.

However, modeling CPSs introduces several challenges due to the heterogeneity of

CPSs. As several engineering and science domains are involved, the modeling and de-

sign process requires the cooperation of several experts from each domain. This might

also require using several modeling and development tools. Another challenge is the

actual modeling of the system. CPSs naturally are composed of physical phenomena,

computations and communications which are modeled differently. A CPS can be mod-

eled using varying models, where the physical system is modeled as a continuous-time

model, and computations and communications are modeled as discrete-event models.

Continuous-time models can be modeled using differential equations which rely on

specialized solvers available in physical simulators. However, integrating such solver-

dependent models with discrete models is a challenging problem in physical modeling

tools and languages [13].

Another challenge is modeling the networking part of a CPS. Integrating commu-

nications into CPSs may affect the behavior of the system due to the inconsistency of

networking in the real world as the network can suffer from packet drops, bit errors,

and low bit-rates. Furthermore, network performance can be affected by physical

aspects such as the locations of communicating entities due to the distributed and

possibly the mobile nature of networked CPSs that relay on mobile and wireless


networks. Such networked systems need to consider detailed modeling of the com-

munication aspects in addition to the physical system itself and the rest of the cyber

components.

2.2 Modeling the Physical Aspects

Tools for modeling and simulation of physical systems range between domain-specific

programming languages to graphical modeling tools, which can also be used for

model-based design and code generation. For instance, Simulink is a commercial

graphical modeling tool for modeling and simulating dynamical systems. Simulink

adds a graphical modeling environment to Matlab, which is based on data-flow blocks

which supports continuous and discrete time models. It also provides model blocks

for digital signal processing, control design, and power systems in addition to other

blocks. A key feature in Simulink is the ability to generate real-time C code that can

be run as a standalone simulation or directly in target hardware, which enables fast

prototyping of real-time algorithms and embedded systems.

Modelica [31] is another environment for modeling physical systems. It is a do-

main specific programming language designed to support declarative, object oriented,

and equation-based modeling. Modelica is developed by the non-profit Modelica As-

sociation. Several commercial tools based on Modelica are available, in addition to

open source implementations such as OpenModelica and JModelica. The Modelica

Standard Library provides a large library of models from different domains including

mechanical, electrical, thermal, fluids, and control systems. A primary emphasis of

Modelica is enabling multi-domain modeling using a standard or unified language.

Language capabilities such as object orientation enable hierarchical modeling and


model reuse. The declarative feature of the language and the ability to specify equa-

tions within the model definition increases the modeling capability.

TrueTime [8], is a simulator for real-time networked control systems. TrueTime

provides Computer and Network blocks which both are discrete-event models. The

computer block provides a model for a real-time kernel with event handlers that rep-

resent I/O and controller tasks. Controller tasks can be written in either C++ or

Matlab. The network block models “send” and “receive” events with several un-

derlying link layer network models. Both Matlalb/Simulink and Modelica can be

integrated with TrueTime.

Another notable modeling tool is Ptolemy II [12], part of the Ptolemy project at

Berkley. Its main emphasis is the modeling and design of hybrid (continuous-time and

discrete-event) and concurrent systems using actor oriented approach. It is composed

of a modular framework of Java packages in addition to a graphical user interface.

Ptolemy II also provides link layer communication model library similar to TrueTime.

Acumen [49] is a domain specific language aimed at modeling hybrid systems.

Acumen introduces a core language with support for hierarchical objects and equations-

based behavior definition. Models written in Acumen can exhibit both discrete-time

and continuous-time behavior. Simulation is performed by interleaving the results of

the continuous laws with the execution of possibly multiple discrete events. Acumen

also integrates a GUI that provides 3D visualization of models.

A shortcoming of the modeling environments discussed is the lack of complete

and realistic models of networking. Some tools attempt to address this limitation by

providing network support such as TrueTime and Ptolemy II. However, these models

are limited to link layer. This limited support for networking ignores an important


aspect of networking represented by upper layer protocols which can contribute to

network performance. Recent efforts rely on co-simulation to tackle this limitation,

which we discuss in Section 2.5.

2.3 Network Simulation

Network simulators have been valuable tools for conducting network research. They

include various models of network infrastructure beginning from the underlying phys-

ical layer up to the higher levels of various Internet, transport and routing protocols.

Network simulators are typically discrete-event simulators. Popular simulators

include OPNET Modeler [37], OMNet++ [36], NS-2 [33] and NS-3 [34]. These sim-

ulators provide a set of libraries of networking models. Depending on the simulator,

the models can be used as a development library or as a component-based modeling

tool through an included GUI.

OPNET Modeler is a commercial closed-source simulator for computer networks.

A graphical modeling interface is used to describe the network topology and node-level

architecture. Network protocols are implemented as finite state machines. Analysis

of simulation results is provided through different visualizations and functions.

OMNet++ is an open source simulation framework, which is mainly used for

network simulation through additional packages and modules. Network models are

written in C++ and assembled into packages using a high level language called NED.

A graphical modeling tool is also available.

One of the most cited simulators in networking literature is NS-2, which provides

an extensive set of models of various network standards and protocols. Network

models are mainly written in C++, while a higher level aspects of simulations are


written in the OTcl language.

NS-3, is state-of-the-art network simulator. It is a complete rewrite of NS-2 in-

tended to overcome some of NS-2’s design and performance issues, offering better

performance and scalability [54]. Simulation core and network models are written in

C++ which is the language used to implement simulation scenarios, in addition to

Python. NS-3 offers sophisticated features such as device emulation and direct code

execution to provide integration with real network stack implementations and actual

testbeds. A more detailed introduction of NS-3 is offered in Section 2.7.2.

2.4 Modeling Mobility

Mobility modeling is a crucial part in simulating and evaluating wireless networks.

Mobility models describe the movements of network nodes. Different models with

different characteristics exist in the literature. A number of these models are built into

network simulators. However, most existing models do not offer detailed movements

of nodes that imitates the movement in reality, and such models are not adequate for

CPSs. As mobility is part of the physical aspect of the CPS, mobility can be modeled

based on the physical model of the CPS for more accurate and realistic mobility.

In this section we overview synthetic mobility models usually found in network

simulators, and then we highlight the shortcomings of such models and the impact

on network evaluations which affect the CPSs. Lastly, we discuss some of the re-

quirements leading towards more realistic modeling of mobility in some applications

of CPSs.


2.4.1 Introduction

Credibility in network simulators owes much to their maturity in processing networks

of various scales, structures, protocols and interfaces. Such simulators are commonly

based on an event-driven structure, which lends itself to a reasonable set of optimiza-

tions for time and accuracy. Within the context of wireless networks, considerations

need to be made for the specific aspects of the wireless communication medium and

mobility — both of which are continuous-time phenomena, and which need careful

modeling to ensure simulation reliability.

Earlier efforts on modeling mobility can be found in works analyzing the per-

formance of cellular networks [22]. Such models, commonly characterized as being

“macroscopic”, were not concerned with the specific location of a mobile node, but

rather the vicinity (specific cell or sector) within which the node lies. Models were

hence reduced to a queuing-based view of the cellular network landscape where nodes

either reside at a specific cell or move between cells at certain assumed rates, es-

sentially creating a birth-death process. This level of detail sufficed the (capacity

limited) nature of cellular networks at the time, when resource allocations were made

either in time or frequency, and the specific effects of node location can be safely

ignored.

Interest in “microscopic” mobility, where the coordinate location of a node is

computed, began to rise toward the end of the 1990s, mainly due to a resurging

interest in mobile ad hoc networks (MANETs). Communications in MANETs do

not go through a central, controlling node such as an access point or a base station,

but are rather made directly between nodes. Evaluation of a MANET protocol thus

heavily relied on knowing where a node is at, in turn resulting in the introduction of


a plethora of mobility models. Among these models are the Random Waypoint and

the Reference Point Group Mobility (RPGM) models [20] (explained in Section 3.1),

which are popular in mainstream network simulators.

The role of microscopic mobility models became more important as the evolution

of cellular networks led to a paradigm of “interference limited” allocations where

network capacity became directly related to where the mobile node was at, and the

data rate at which it is transmitting. This was more the case as cellular networks

shifted from a connection-oriented operation to a datagram-centric one, and as cell

size (i.e., a cell’s coverage area) was substantially reduced, especially in urban areas.

Meanwhile, the introduction of location-based services meant that mobility modeling

also mattered in simulated service evaluations.

Today, efforts continue to generate realistic mobility in modeling wireless net-

worked CPSs, where physical behavior is related to both the data exchanged and

the nodes’ surrounding physical context. Examples of such systems can be found in

Vehicular Ad Hoc Networks (VANETs), where serious stakes depend on inter-vehicle

communications and communications between vehicles and road-side infrastructures,

significantly depending on exact vehicle location and speed. Similar emphasis can also

be found in analyzing networked robotics and swarms. Increasingly, the importance

of realistic mobility modeling has led to integrated simulation environments.

In the following section we offer a survey on microscopic mobility models that have

been used in network simulators. We highlight the advantages and disadvantages of

the different models, especially the impact of mobility model choice on the correctness

of network simulation.


2.4.2 Overview of Mobility Models

A mobility model describes various mobility behaviors, including movements and

changes in speed and direction. Mobility models can be generally grouped into two

broad categories: trace-based and synthetic. Trace-based models are essentially data

collected from real networks used to dictate the movement of nodes in the simulation.

Such models do offer realistic mobility, but do not allow for reactive simulations,

and may be hard to obtain. Synthetic mobility models, on the other hand, compute

the mobility based on predefined mobility assumptions and settings, and respond to

changes in the simulated environment.

Generally, synthetic models can be classified further based on randomness in

speeds and directions or destinations, temporal dependency of velocity, and whether

geographic obstacles or restrictions exist. As well, some synthetic models capture the

mobility of a group of nodes [7].

Entity Mobility Models

One class of mobility models is based on random movements of mobile nodes. Models

in this class are usually called Random Entity Mobility Models, as attributes assigned

to one node are independent from those assigned to all other nodes in the simulation.

In this class of models, each node is assigned a random speed and either a random

direction or destination point. Once a node reaches its destination, or travels for

specified period of time, it either pauses for a short time or travels immediately to a

new selected destination or in a new selected direction, depending on the model cho-

sen. Three popular random entity mobility models are Random Waypoint, Random

Walk [7], and Random Direction [44].


0 100 200 300 400 5000

100

200

300

400

500

(a) Random Direction Mobility

0 100 200 300 400 5000

100

200

300

400

500

(b) Random Waypoint Mobility

Figure 2.2: Movements of a node in Random Direction and Random Waypoint Mo-bility Models.

Some models take into account geographic restrictions and physical obstacles in

order to simulate situations that take place in urban areas. In such models, however,

geographical restrictions are handled by limiting node mobility to fixed paths – an

assumption that can be justified given that much street or in-building mobility is path-

constrained. Such models can be represented as graphs; the Pathway model [51], City

Section model [11, 45] (also called the Manhattan Grid Model), and Obstacle mobility

model [21], are examples of models with geographic restrictions.

The aforementioned mobility models, can be commonly found in mainstream sim-

ulators such as GloMoSim [17], OPNET [37], NS-2 [33] and NS-3 [34], or can be

available through their extensions. The models, nevertheless, suffer from several

drawbacks that affect the accuracy of the simulation. For instance, nodes in Ran-

dom Waypoint and Random Direction undergo unrealistic movements such as taking

sharp turns and sudden stops (i.e., without any deceleration) [4]. Memorylessness is


also a common characteristic in such models, whereby no correlation or dependence is

enforced between consecutively assigned speeds. Several models have been proposed

to overcome these drawbacks, including the Gauss-Markov [30] and Smooth Mobility

[4] models.

For instance, the Gauss-Markov model introduces temporal dependency of nodes’

velocity by having the velocity of a node at a certain time period depending on the

velocity at the previous time period. The model further incorporates a tunable mem-

ory level parameter for adjusting the randomness of the model. The value of the

parameter determines the degree of which the new velocity is dependent on the previ-

ous velocity or a randomly generated value. The Smooth Mobility model targets the

problem of sharp turns and sudden accelerations by introducing smooth increments

of speeds and direction changes. Both velocity of nodes and direction are affected

by previously used velocities and directions. This smoothing more closely matches

realistic movements with respect to speed, acceleration and direction change.

An important aspect of utilizing a mobility model for validation is how long it

maintains specific evaluation criteria. Controlling average speed distribution or av-

erage longest distance covered becomes of particular importance in certain scenarios,

e.g., where handover protocols are evaluated in cellular networks. An evaluation of

steady-state characteristics of the Random Waypoint model was made in [4]. It was

found that nodes in Random Waypoint have a tendency to cluster at the center of

the simulation area as the simulation progresses. Suggestions were made in [4] to

alleviate the effects of this behavior.


Figure 2.3: The movement of a group in RPGM.

Group Mobility Models

In the models described above, nodes move independently from each other and do

not capture instances where a group of nodes can change their mobility, for example,

following some leader node or in response to the movement of an external entity. To

this end, group mobility models capture the behavior of nodes that work in some

form of cooperation. Generally, a group model allows for two movements, a move-

ment of the group collectively, and movements of individual nodes within the group.

Models such as the Random Walk are utilized for individual node movements. An

example of models that work in this manner is the Reference Point Group Mobility

(RPGM) model, which allows for various group mobility patterns including column,

nomadic, and pursue mobility models [20, 46]. Such patterns have direct applications

in simulating scenarios involving rescue, sensing, tracking, and military operations.

In RPGM, the movement of the group is directed by a central point to the group,


a “logical center” that determines the path the group takes, as well as the speed,

acceleration, and direction. Each node is paired with a reference point that follows

the movement of the center. Initially, nodes are uniformly distributed within a certain

range around the central point. Nodes are also placed around their reference points,

and as the group advances towards the goal, the reference points advance, and each

node follows its reference point and then moves around it according to a random entity

model. The central point defines the trajectory of the group as a whole (either random

or a predefined path), while reference points define the movements of individual nodes

around their reference points within the group. Figure 2.3 shows the placement of

nodes around their reference points as they move from one location to another. This

model is designed to produce various scenarios that involve multiple groups if provided

a proper combination of parameters [20].

2.4.3 Impact of Mobility on Network Performance

Increasing interest in reliably simulating MANETs motivated the distinct efforts made

in [43, 7]. The goal of any network simulation is to test various aspects in an envi-

ronment that, as much as possible, matches practical deployment and operation. In

these two works, the choice of mobility model was shown to have a non-negligible

effect on the results. Affected performance metrics included energy consumption,

routing overhead, path length (hop count) traveled by the packets, end-to-end delay,

and packet delivery rate. Intuitively, faster movements increase energy consumption

— not only for energy expended in mobility, but also in packet re-transmissions. In-

deed, a frequent change of network topology affects packet delivery due to broken

links as a pair of nodes move distantly apart. A node’s surroundings (movements


or communication obstacles), directly dependent on the node’s location, also affect

simulation results [43].

The work in [7] also examines the effect of mobility model choice. In [7], the

Random Waypoint model is shown to result in a high packet delivery rate and low

end-to-end delay and hop count due to the model’s density wave phenomenon in

which nodes tend to converge to the center with time. Meanwhile, and for the same

set of protocols evaluated, choosing the Random Direction model results in higher

hop counts and end-to-end delays, but a low packet delivery rate. The difference in

the results from those of the Random Waypoint was largely attributed to the border

effect 1 utilized in the Random Direction model, as this function eliminates the density

wave phenomenon.

Other studies have been presented within the MANET contexts, but the two noted

here suffice to highlight the serious consequences of selecting one mobility model over

the other. These consequences are not alleviated by a passive conformity in selecting

a specific model for most performance evaluations. At the same time, the models

discussed thus far, including the smoothed models, still lack in representing a natural

mobility — the need for which increases substantially when considerations for aspects

such as actuator qualities, terrain changes, impacts, and driving patterns have to be

made.

The need for careful selection is not limited to mobility models. In many simula-

tions for wireless mobile networks, accurate modeling needs to involve both mobility

and the wireless channel. The effect of using a more accurate channel model on the

formation of a group of networked autonomous robots was studied in [32]. The work

1In the Random Direction mobility model, nodes travel in the specified direction to a selected

point on the boundary of the simulation area. Then, in the next step, a new direction is chosen.


evaluated the impact on packet drops and network topology in a field with obstacles.

The scenario involved robots following a leader that has a predefined path, and where

follower robots are expected to avoid obstacles in the field to maintain good commu-

nication channels. In such a setting, dropped packets directly influence the robots’

movements made to better end-to-end communication. To demonstrate the effect of

accurate channel modeling, the authors utilized Matlab for computing the channel

conditions instead of utilizing the network simulator’s own computation. Consider-

able variations in the results were shown to result from the choice of the channel

model.

2.4.4 Modeling Mobility for VANETs and Networked Robotics

Simulating wireless networked CPSs requires careful attention, if only for the possibly

sizable human and monetary assets at stake. In what follows, we focus on how

mobility is modeled for two specific CPS applications, namely VANETs and networked

robotics. In both these applications, the specific coordinate location of the CPS may

have non-negligible consequences. In the example noted above, the specific location of

a robot directly affected communication quality. In the context of VANETs, correct

location information becomes a crucial safety requirement [14].

Mobility for VANETs

In simulating VANETs, researchers have used real mobility traces since they are

clearly more accurate than random models or other models such as the Manhattan

grid model. Real traces can be difficult to collect in order to be used in simula-

tion. Furthermore, it is not possible to simulate specific scenarios other than what


is described in the traces, which makes this approach very limited. Recent appli-

cations of VANETs and Inter-Vehicle Communication (IVC) protocols require more

detailed modeling at the microscopic level, describing various aspects of vehicles, traf-

fic constraints, in addition to driver behavior models. Microscopic models emulate

the behavior of individual vehicles independently. Additionally, driver-behavior is a

challenging aspect since the impact involves individual vehicles (microscopic effect)

as well as the high level flow of traffic, which affects mobility in general [14]. There

are a number of simulators that have been developed for road traffic simulation such

as VISSIM [52], and SUMO [27].

Mobility for Networked Robotics

Network simulators offer advanced and detailed models of communications as well

as network protocols and routing. However, there is a need for models of physical

robotics and their dynamics within the surrounding environment. This need is re-

alized by existing robotic simulators, which model various components of robotics,

including mechanical parts such as wheels, engines, sensors, and actuators. A detailed

modeling of the surrounding environment is possible with such simulators, allowing

for a realistic simulation of robotics, including robot mobility [48]. Some robotic

simulators utilize the same controllers code used in the actual robots. A controller

program can be used unchanged either in the simulation or in the real robot. This

allows researchers to use the same controllers similarly. However, these simulators

do not include detailed models of the network, if they have any network simulation

capability, they have only simplistic models. ARGoS [38] and Player/Stage [39] are

two examples of open source robotic simulators.


2.5 Co-simulation

Co-simulation allows for integrating heterogeneous models from different simulators,

typically from different domains such as mechanical systems and networking. Com-

bined models can interact with each other during the simulation through an inter-

facing mechanism. Co-simulation environments attempt to fill the void in existing

modeling tools and overcome the lack of detailed models of computing and com-

munication networks. This enables using established models without having to re-

implement them in other simulators. In such integrated environments, the combined

simulator can provide complete detailed models for both physical and cyber aspects

of a CPS. For instance, a physical modeling environment provides the physical model

while a network simulator provides the communication model.

Typically the integration combines solver-dependent continuous-time models with

discrete-event models. To enable the integration between different models and sim-

ulators, a global execution and synchronization mechanism is required to facilitate

the co-simulation. A global execution mechanism governs the execution of the co-

simulation and the switching between simulators. Execution switching allows each

simulator to take its turn in order to perform its own simulation. The switching can

be scheduled according to predefined time steps or it can be dynamically adjusted

depending on variable time steps or state events in the continuous model, depending

on how each simulator works. The mechanism also is determined by the simulator

appointed as the master simulator which enslaves the other simulator and controls the

execution. The points in simulation time when switching takes place can be used as

communication points to allow synchronization. At these points, simulators exchange

information about the state of models or some events, which also allows for model


interactions.

Co-simulation environments may require some form of interaction between mod-

els. To give an example, consider performing a simulation of a set of networked

robots. A robotic simulator can be used to utilize its robotic and controller mod-

els, and a network simulator can be used to simulate the network. To perform the

simulation, this would require constructing models that represent the robots in the

robotic simulator. In the network simulator, we would need to construct a set of

network nodes for each robot in order to represent the network capability of robots.

In this simulation environment, robots should be linked to their respective network

nodes during the simulation. The robot models will perform a control algorithm that

may include sending messages over the network between robots. The communication

functionality are forwarded to the network simulator.

The network simulator also may utilize mobility information (i.e., positions of

nodes) from the robotic simulator and updates the mobility of the nodes in the net-

work simulator in order to perform the network simulation. The network simulator is

informed about the messages exchanged between robots (e.g., as a result of the control

algorithm being simulated) in order to simulate the networking activity. As nodes

receive packets, respective robots in the robotic simulator are notified to consider

messages received.

Simulator integration translates to software development challenges. Extending

one or both of the simulators, and/or developing an intermediate program may be

required. Several approaches can be used depending on how individual simulators

are implemented. For instance, some simulators are exposed as software development

libraries. In such simulators, models are implemented as classes which can be reused


and extended, such as in Ptolemy II, NS-2 and NS-3. However, some libraries are

written in different languages and target different platforms, which cannot be inte-

grated easily. This can be overcome by workarounds such as language bindings which

usually are not straightforward and depend on language support.

Some modeling tools such as Simulink and Modelica provide an external program-

ming interface that can be utilized. Another approach is employing a server-client

model for integrating simulators. The server-client model allows cross-platform soft-

ware interaction, but a disadvantage of this is it can be more difficult to implement

and debug. This approach is usually implemented using several inter-process com-

munication techniques provided by most operating systems, such as network sockets,

pipes, shared memory, and memory mapped files. These techniques differ in terms of

ease-of use, portability, availability in operating systems, and performance. Network

sockets technique is a common choice because of its ease of use and portability across

all platforms and operating systems.

A number of co-simulation tools have been recently developed for different appli-

cations of CPSs. In the following section we present some representative examples.

2.5.1 Co-simulation Environments

RoboNetSim [28] is a simulator for multi-robot systems developed by IDalle Molle

Institute of Artificial Intelligence (IDSIA). The objective of RoboNetSim is to make

a realistic networked multi-robotic simulation environment by adding detailed com-

munication models to the simulation. This framework provides an interface between

ARGoS, a multi-physics-based simulator for large heterogeneous robotic swarms, and


network simulators NS-2 and NS-3. The environment extends ARGoS with a com-

munication device model that relays communications performed by a robot to a cor-

responding node in NS-3, while NS-3 relies on robot positions for mobility. However,

this interaction between robots and node models requires an open network socket con-

nection for each robot/node mapping which may require many ports to be reserved

for the co-simulation.

Several co-simulation tools have been proposed for Networked Control Systems

(NSC) such as the work presented in [2] which adds the ability to model NCS within

NS-2 using several approaches. The most notable approach is integrating the Mod-

elica environment for modeling control system dynamics with NS-2. The use-cases

examined do not involve mobility. Another tool presented in [19] targets wireless NCS

and integrates Simulink and OPNET for network simulation. Mobility was based on

traditional mobility models provided by OPNET.

The Networked Control Systems Wind Tunnel (NCSWT) [15], is another tool

for modeling and simulating NCS. It interfaces Matlab/Simulink with NS-2. NC-

SWT utilizes a model-based approach to generate simulation runtime models from

abstract design models using several domain-specific modeling languages for specify-

ing the control system dynamics and networking. It also follows the HLA (High Level

Architecture) standard for constructing the components of the integrated simulation.

PiccSim [26] is also another NCS co-simulation tool that integrates Simulink and

NS-2. It offers a full toolchain for design, simulation, and implementation, as it is

capable of generating embedded code to use on actual hardware.

BARAKA [29] is also a co-simulator for Sensor/Actuator Networks (SANETs).

It integrates physical aspects of robotics and sensors with the networking aspects in


OMNeT++ [36] used for network simulation. OMNet is C++-based network simu-

lator. The Open Dynamics Engine (ODE) [35], an open source library for simulating

rigid body dynamics, is used for simulating physical robots. BARAKA extends OM-

Net++ with a set of classes that provide an interface to ODE. Classes include objects

that represent robots which are created and simulated in ODE. Robot controllers are

written as application layer programs in OMNet++, and mobility is based on the

physical world simulated in ODE.

For VANETs, iTETRIS [18] is an integrated simulation platform for large-scale

cooperative road traffic management. iTETRIS integrates SUMO (Simulation or

Urban Mobility) and NS-3. It provides a realistic environment based on an open

source architecture that links the traffic simulator with the network simulator in real

time, which allows for dynamic control of traffic based on the urban mobility provided

by SUMO and the wireless network simulated in NS-3.

2.6 Discussion

Some of the co-simulation works presented above serve specific use-cases, such as

robotics-based simulations or vehicular networks. While such tools are beneficial for

their intended purposes, some important features are still unavailable. RoboNetSim

for instance utilizes the mobility provided by the robotic simulator but it does not

seem to allow customization of the networking scenario compared to BARAKA. In

BARAKA, while all physical and networking models are constructed in the network

simulator, the network scenario is customizable but the physical model is limited to

a pre-built robot model.

The ability to derive mobility from the physical model is an important feature in


some of the robotic co-simulation tools, including iTETRIS, but physical models are

limited to robots or automobiles. Other works that target NCS are more generic in

regards to physical modeling, which also depend on the library of physical models

provided by the physical modeling tool. However, deriving node mobility from the

physical model does not seem to be an objective of such tools with the exception of

PiccSim which was extended to support mobility [40].

A main motivation for co-simulation for CPS, especially in regards to network

simulation, is addressing the incapability of modeling physical features accurately

within network simulation. A target co-simulation environment that would address

such a need include:

• The ability to construct physical and network models together with ability to

customize the models used.

• The ability to derive nodes mobility from the physical model.

• Ability to include general physical models into the network simulation.

• Integrating available and well established tools in terms of reliability and per-

formance.

Furthermore, tools that are open sourced and extensible can be easier to integrate

together. Other important factors in choosing the tools include ease of learning and

use, which contributes to the overall usability of the co-simulation environment.


2.7 Modeling Physical Systems and Computer

Networks in Acumen and NS-3

In the following chapter, we propose a co-simulation environment that integrates

Acumen with NS-3. In this section, we provide a brief introduction to modeling

physical systems using Acumen, and computer network simulation NS-3.

2.7.1 Acumen

Acumen is programming language for modeling and simulating cyber-physical sys-

tems. The language is designed to express the hybrid nature of CPSs as continu-

ous/discrete systems. Acumen comes with a graphical user interface that includes

a code editor, controls for starting/pausing the simulation, and a live graphing view

of the state of the models being simulated, as well as a 3D view for models that

implement three-dimensional representation.

Acumen as a language incorporates the concept of objects as a modeling construct.

Objects are instances of defined classes that contain private state variables that repre-

sent the state of the object. Classes also contain the rules that implement behavior.

Variables can represent both discrete and continuous state over time. To support

this model of objects, the simulation mechanism adopted by Acumen incorporates

discrete and continuous stages to execute objects.

To illustrate, Listing 2.1 shows a simple model for a bouncing ball, which falls

vertically and bounces on the ground multiple times. This model is an example

of hybrid system as it exhibits both discrete and continuous behavior. The discrete

behavior can be considered as the collision of the ball with the ground and the sudden


change of velocity when the ball bounces. The continuous variables of the model are

the position and velocity of the ball.

In Listing 2.1, the class Ball implements the state and behavior of the ball. The

private section of the class definition contains variable definitions with initial values.

x is the vertical position of the ball. Primed variables, namely x’ and x’’, are the

first and second derivatives of x (representing velocity and acceleration, respectively).

Assigning derivatives determines future values of x. The rest of the class definition is

the rules the govern the state, which are executed at every step. The rules are usually

implemented by assignments (manipulating private variables) and control statements

such as if and switch statements.

As seen in the listing there are two kinds of variable assignments : discrete assign-

ments, which are denoted by :=, and continuous assignments, denoted by =. Acumen

model of execution adopts a mechanism that allows for both discrete and continu-

ous steps within fixed time steps. Acumen executes the body (rules) of the class for

each instance at every time step. Every time step has two stages. In the first stage,

only discrete assignments are executed (possibly multiple times without advancing

the time). In the second stage, continuous assignments are executed which may in-

volve solving the equations, then the time is advanced. For a detailed description and

rationale behind this model, refer to [49] and [1].

In addition to the Ball class we have the Main class where simulation attributes

are set (through simulator parameter) such as simulation time length and the size of

the time step. Also, initial instances of other classes (Ball in this case) are created.

It is similar to the main function in imperative languages, but here it is in an object

instead of a function. 2

2The body of the main class is omitted for simplicity, and also because AcumenNS3 generates it


The model is described as follows. Acceleration of the falling ball: x(t)′′ = −g ,

while after collision: x(t)′ = kx(t) and x = 0, where g is the gravitational acceleration

and k is a coefficient that relates velocity before and after collision.

The class Ball models two states of the ball represented by the mode variable.

The value of mode changes at the moment of impact with the ground from "Fly" to

"Bounce", and then back to "Fly". The moment of impact is detected as soon as x

and x’ are less than zero (Lines 7-8). The other change is after the impact (Line 15).

Figure 2.4 shows Acumen GUI after running the model. The first plot from the top,

shows the position x(t), while the second shows the velocity x(t)′′. Both discrete and

continuous behavior can be seen.

automatically. See Chapter 4.


Figure 2.4: Bouncing ball model in Acumen GUI.

2.7.2 Network Simulator 3 (NS-3)

Network Simulator 3 is a new simulator that does not share any design or code with

NS-2. It consists of a collection of modules written mostly in the C++ programming

language. Users are expected to use either C++ or Python bindings to write simu-

lation scenarios. That is, defining or using preexisted network models and executing

the simulation are implemented by writing code (NS-3 scripts). Users are expected to


Listing 2.1: Simple bouncing ball model in Acumen.

1 class Ball()

2 private

3 mode:="Fly"; x:=1; x’:=0; x’’:=0;

4 end

5 switch mode

6 case "Fly"

7 if x < 0 && x’ < 0

8 mode := "Bounce"

9 else

10 x’’ = -9.8

11 end

12 case "Bounce"

13 x’ := -0.8*x’;

14 x := 0;

15 mode := "Fly"

16 end

17 end

1819 class Main(simulator)

20 // Code omitted

21 end

have adequate programming experience in order to use NS-3, as there is no included

graphical interface.

NS-3 can be looked at as a development framework that includes reusable classes,

helper objects and models needed to facilitate the modeling and simulation. A typ-

ical NS-3 script constructs such models required to describe the simulation, such as

defining network topology, setting traffic generators, and carrying out the simulation

scenario and producing results.

The NS-3 framework consists of a number of modules, including a simulation core

responsible for scheduling and executing the discrete events of the simulation. The

rest of modules consist of network models and helper classes.


Network models represent the various network components which are executed

during the simulation. Network models include for instance: network nodes, network

devices (Network Interface Controllers or NICs), channels, protocol stacks, and pack-

ets. Such models are represented by classes that can be used by users. For instance,

NS-3 provides abstract classes such as Node, NetDevice, PointToPointChannel3,

WifiChannel, and Packet. Those classes follow an object oriented design where

they are extended by concrete classes that implement specific behavior of an actual

medium, channel or protocol stack.

Helper classes hide some unnecessary details and automate tedious tasks in con-

structing the network models. For example, WiFi helper classes automate construct-

ing network infrastructure using required models without requiring the user to con-

struct them manually. Other helper classes include many useful classes such as ran-

dom number generators, packet tracers, and data collectors.

Thereby, in a nutshell, writing an NS-3 simulation script entails a number of steps,

which are: creating network topology, constructing network models, generating traffic,

performing the simulation usually by invoking the NS-3 scheduler. To demonstrate

this, Listing 2.2 shows a simple NS-3 script that creates a simple WiFi Ad-hoc network

of two nodes.

In Listing 2.2, Lines 22-23 create two nodes, contained in the NodeContainer

object. Containers are helper objects the simplify making changes to a collection

of nodes while creating network objects. Lines (25-27) create a WiFi helper object

that helps in assembling physical and MAC (Medium Access Control) layer models

3For simple point to point channels


(including devices) on nodes. Note that we tell the WiFi helper which 802.11 stan-

dard we want. Lines (29-33) create the actual helper objects for the physical layer

and channel models and also set the propagation delay and loss models with the ap-

propriate parameters. Lines (35-38) create MAC layer helper objects, which set the

type of the MAC to ad hoc; In line 38, the original WifiHelper objects creates the

whole configuration of WiFi models and applies them the to nodes container, and

that yields a container of devices which will be later configured with IP (Internet

Protocol) addressing.

Lines 40-46, sets the mobility of nodes. The ListPositionAllocator object

allocates a list of initial positions for nodes. The MobilityHelper object sets the

initial locations (using the list provided) and the mobility model to a static model,

and then applies location and mobility to nodes.

Configuring and installing the Internet stack, the routing protocol and the IP

addressing scheme is applied in Lines 48-53. Then, in the remaining parts of the

NS-3 script, we create network sockets for traffic generation (Lines 55-65). NS-3

includes network sockets API similar to those provided by BSD Unix. In line 59,

we set a callback to the function ReceivePacket, so this function will be called

whenever a packet is received. For traffic generation, NS-3’s event scheduler can

be used to make calls to the function GenerateTraffic in order to use the socket

created to send packets periodically. Finally, the simulation can be started by calling

Simulator::Run.

Line 66 shows an example of the tracing functionality in NS-3. For instance,

PCAP (Packet Capture) trace files can be generated for network devices.


Listing 2.2: Basic NS-3 simulation script.

12 // Headers omitted.

34 void ReceivePacket(Ptr <Socket > socket)

5 {

6 NS_LOG_UNCOND("Received one packet!");

7 }

89 static void GenerateTraffic(Ptr <Socket > socket , uint32_t

pktSize , Time pktInterval )

10 {

11 socket ->Send(Create <Packet >( pktSize));

12 Simulator :: Schedule(pktInterval , &GenerateTraffic , socket ,

pktSize , pktInterval);

13 }

1415 int main(int argc , char *argv [])

16 {

17 double rss = -80; // -dBm

18 uint32_t packetSize = 1000; // bytes

1920 Time interPacketInterval = Seconds (1.0);

2122 NodeContainer c;

23 c.Create (2);

2425 WifiHelper wifi;

26 wifi.EnableLogComponents ();

27 wifi.SetStandard(WIFI_PHY_STANDARD_80211b);

2829 YansWifiPhyHelper wifiPhy = YansWifiPhyHelper :: Default ();

30 YansWifiChannelHelper wifiChannel;

31 wifiChannel.SetPropagationDelay("ns3::

ConstantSpeedPropagationDelayModel");

32 wifiChannel.AddPropagationLoss("ns3:: FixedRssLossModel","Rss

",DoubleValue(rss));

33 wifiPhy.SetChannel(wifiChannel.Create ());

3435 NqosWifiMacHelper wifiMac = NqosWifiMacHelper :: Default ();


36 wifi.SetRemoteStationManager("ns3:: ConstantRateWifiManager",

"DataMode",StringValue("DsssRate1Mbps"), "ControlMode",

StringValue(phyMode));

37 wifiMac.SetType("ns3:: AdhocWifiMac");

38 NetDeviceContainer devices = wifi.Install(wifiPhy , wifiMac ,

c);

3940 MobilityHelper mobility;

41 Ptr <ListPositionAllocator > positionAlloc = CreateObject <

ListPositionAllocator >();

42 positionAlloc ->Add(Vector (0.0, 0.0, 0.0));

43 positionAlloc ->Add(Vector (5.0, 0.0, 0.0));

44 mobility.SetPositionAllocator(positionAlloc);

45 mobility.SetMobilityModel("ns3::

ConstantPositionMobilityModel");

46 mobility.Install(c);

4748 InternetStackHelper internet;

49 internet.Install(c);

5051 Ipv4AddressHelper ipv4;

52 ipv4.SetBase("10.1.1.0", "255.255.255.0");

53 Ipv4InterfaceContainer i = ipv4.Assign(devices);

5455 TypeId tid = TypeId :: LookupByName("ns3:: UdpSocketFactory");

56 Ptr <Socket > recvSink = Socket :: CreateSocket(c.Get (0), tid);

57 InetSocketAddress local = InetSocketAddress(Ipv4Address ::

GetAny (), 80);

58 recvSink ->Bind(local);

59 recvSink ->SetRecvCallback(MakeCallback (& ReceivePacket));

6061 Ptr <Socket > source = Socket :: CreateSocket(c.Get (1), tid);

62 InetSocketAddress remote = InetSocketAddress(Ipv4Address("

255.255.255.255"), 80);

63 source ->SetAllowBroadcast(true);

64 source ->Connect(remote);

6566 wifiPhy.EnablePcap("wifi -simple -adhoc", devices);

6768 Simulator :: ScheduleWithContext(source ->GetNode ()->GetId (),

Seconds (1.0), &GenerateTraffic , source , packetSize ,

interPacketInterval);

69


70 Simulator ::Run();

71 Simulator :: Destroy ();

7273 return 0;

74 }

Chapter 3

The AcumenNS3 Co-simulation

Environment

In this Chapter, we introduce our co-simulation environment. We have sought to

develop a co-simulation environment that fulfills our expected features discussed in

Section 2.6. In doing so, we have chosen two environments, namely NS-3 and Acu-

men. By design, the co-simulation environment, called AcumenNS3, enables network

modelers to supplement their models with realistic characterizations of physical en-

vironments.

In this chapter, we first motivate our choice for both the network and physical

modeling environments, describing at length their individual inviting features. We

then provide an overview of our design approach. The architecture of the environment

is then detailed next, together with an explanation of its components and their indi-

vidual objectives. We also show how the mobility can modeled based on the physical

model in Acumen, and how physical state is accessed from within NS-3.

41

CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 42

3.1 Design Overview

AcumenNS3 co-simulation environment is made by integrating Acumen, for physical

modeling, with NS-3, for network simulation. The environment is designed with the

following goals in mind:

1. the ability to integrate physical modeling with NS-3,

2. the ability to rely on physical models for mobility in NS-3,

3. requiring little amount of effort from NS-3 users to use the interface,

4. providing a seamless way to access and manipulate the state of Acumen models

from NS-3.

Using our environment, a physical model can be written in Acumen to describe

a physical phenomenon which may include mobility or other physical phenomena,

and an NS-3 script can be written (in C++) to describe the networking scenario.

Then, the AcumenNS3 environment automatically sets the simulation parameters

in a unified manner to both physical and networking models and instantiates the

required Acumen objects. The environment runs both simulators in a synchronized

manner and transfers the state of Acumen models between the simulators during the

simulation. This allows AcumenNS3 to handle mobility in NS-3 based on the physical

model and to allow seamless access to the state of Acumen models from NS-3 scripts.

By design, the user specifies the scenario of the simulation in NS-3 scripts, which

normally describe network topology and overall network scenario. AcumenNS3 en-

ables the interfacing with Acumen models during the co-simulation. The interface


Figure 3.1: AcumenNS3 client-server model.

allows the user to access the physical state from the NS-3 scripts by retrieving spe-

cific variables or even changing the state. For example, the user can write a simple

controller to control a physical entity modeled in Acumen. As a result of this design,

NS-3 is aware of both the network and the physical models provided by Acumen.

On the other hand, Acumen models are not aware of the networking aspects of the

modeled system. Users of AcumenNS3 environment write NS-3 scripts and utilize

Acumen models through the AcumenNS3 interface in their scripts.

The integration is implemented by extending both Acumen and NS-3. The above

mentioned co-simulation mechanism requires NS-3 to be the master simulator that

controls the co-simulation. At the lower level, the interaction between Acumen and

NS-3 follows a client-server model where Acumen, acting as the server, exposes its

state to NS-3, as the client, which receives the physical state, simulates the network

then sends state updates back to Acumen. Acumen was extended with a “server

mode” and NS-3 was extended with a set of components that drives the co-simulation


of Acumen and NS-3, and the access to the physical state in Acumen.

3.2 Why Acumen and NS-3

Several physics and network modeling and simulation tools exist; here we show the

reasoning behind choosing Acumen and NS-3 as the basis of our co-simulation envi-

ronment.

For network simulation, NS-3 is a mature network simulator and is constantly

under development. It offers a strong foundation for a variety of network models in

addition to an extensible design. Compared to other network simulators, it offers

flexibility and scalability. It performs better than most mainstream simulators in

simulating networks with a large number of nodes [54]. While it is free and open

source, it is well documented and maintained and has a large community of users

and contributors. Furthermore, NS-3 is a library written in C++, which is also the

language required to write simulation scripts 1 and extensions, which offers flexibility

to develop the co-simulation environment. As well, NS-3 source code translates to

efficient performance, which leads to restricted overhead to the overall performance

of the co-simulation. Integrating a physical modeling tool such as Acumen into NS-

3 can be a great advantage for network modelers who need to incorporate physics

modeling and mobility.

For physics modeling, Acumen provides a powerful modeling capability for hybrid

systems while maintaining simplicity in the language. Compared to other environ-

ments such as Simulink, a textual language such as Acumen has better expressiveness

1NS-3 offers Python scripting which can be more convenient for some. However, C++ is still

required to use AcumenNS3


Figure 3.2: Architecture of the co-simulation environment.

in describing the equations of the physical system, instead of the block-based or graph-

ical diagramming in Simulink and Ptolemy II. It is free and open source, thus very

accessible, in addition to the ability to modify it with the functionality needed to

integrate with an external simulator. This functionality enables Acumen to run in a

“server mode” that serves model state during the simulation. It requires very little

effort to learn and use. It offers 3D visualization capability which helps in observing

the behavior of models. As a result, we find Acumen a feasible choice as a physical

modeling tool to integrate with NS-3.

3.3 AcumenNS3 Architecture

The interface comprises several components that work on top of the NS-3 simulator,

while Acumen has the functionality required to enable server mode and state ex-

change. The higher level architecture of the interface is depicted in Figure 3.2. User

simulation setup refers to NS-3 scripts that define the network simulation scenario.

The individual components and the interactions between them, shown in Figure 3.3,


are as follows.

• AcumenNS3 Scheduler: The main engine that carries the operation of the

co-simulation. It runs on top of NS-3’s discrete-event scheduling and simulation

core.

• Mobility Controller: Offers an alternative mobility of standard mobility mod-

els in NS-3. It is responsible for the mapping between NS-3 nodes and corre-

sponding instances of the models that dictate movements in Acumen. It ensures

that node locations are in-sync according to Acumen.

• Acumen Value Store: Represents the current state of Acumen at the cur-

rent simulation time. It also provides access to object values during the co-

simulation.

• Shared Variables Controller: Provides a higher level access the physical

state as regular C++ objects. It works on top of the value store component.

• Configuration Manager: provides access to the configuration file which con-

tains simulation parameters and options.

• Acumen Client: maintains the underlying connection with Acumen, including

low-level Send and Receive operations.


Figure 3.3: Architecture of the AcumenNS3 interface.

3.4 Co-simulation Overview

AcumenNS3 components, working on top of NS-3, dictate the execution of the co-

simulation and maintain the simulation time. The co-simulation scheduler knows

beforehand the length of the simulation time, the number of mobile nodes, the time

step size used in Acumen, and other parameters specified in a configuration file. The

scheduler will signal Acumen to proceed and simulate the first time step. Once the

first time step is completed, Acumen pauses and sends the complete model state

to NS-3. At this point, Acumen is one time step ahead of NS-3’s simulation time.

Then, the AcumenNS3 scheduler reads the state and allows NS-3 to simulate one

time step to catch up with Acumen. NS-3 then pauses the simulation and reports

any changes to the physical state back to Acumen. Up to this point in simulation

time, the two simulators have executed to the same point of time, and Acumen is

signaled to simulate the next time step. The co-simulation continues in this fashion


Figure 3.4: Timeline of the Co-simulation.

until the simulation time ends.

The flow of the co-simulation is shown in Figure 3.4. How NS-3 integrates with

Acumen is determined by the size of the time step in Acumen. Since NS-3 simula-

tion is based on discrete-events, AcumenNS3 scheduler schedules synchronization

events in NS-3 in order to match Acumen time steps and continue/pause the simu-

lation to be able to execute the co-simulation tasks such as mobility. Synchronization

events in NS-3 and time step marks in Acumen represent the communication points

between Acumen and NS-3.

3.4.1 Role of Acumen Models

Acumen is only responsible for modeling the physical aspects of the system. Acumen

models implement the physical behavior and can implement simple control and state

change on their own based on internal state events. However, Acumen models cannot

for example initiate network messages sending and receiving, as network activities

are delegated to NS-3. NS-3 scripts can perform control and state change to Acumen


models and initiate network activities on behalf of the physical model. For instance,

if we have an Acumen model of a group of mobile robots that communicate with

each other, the robot model implements the behavior of movements on the terrain.

In NS-3, we would have network nodes that are mapped to their corresponding robot

model instances. A control algorithm that involves sending messages over the network

between robots can be implemented in NS-3. The ability of Acumen models to

respond to messages and change their behavior accordingly is implemented in NS-

3. When nodes receive a network message that should result in a change in the state

of the robot in Acumen, that state change will be performed by the receiving node

in NS-3, as the robot model in Acumen is accessible from NS-3.

3.5 Operations of AcumenNS3

As described above, NS-3 is considered the master simulator that dictates the ex-

ecution of the co-simulation and maintains the simulation time. This is the duty

of our co-simulation scheduler component. An overview of the workflow of the co-

simulation is given in Section 3.1. In the following sections, we discuss in more detail

the operations of AcumenNS3.

3.5.1 Configuration and Initialization

During the initialization of the co-simulation, the configuration manager component

reads the configuration file which contains parameters necessary to perform the co-

simulation. Parameters include the length of the simulation, and the size of the

time step in Acumen, among other parameters related to mobility and the physical


model which are described in more detail in Chapter 4. This information is used

to initialize the co-simulation and establish the underlying connection with Acumen

using the Acumen Client component. Key functionalities such as mobility, physical

state access using shared variables are also initialized.

3.5.2 Modeling Mobility

One of the objectives of AcumenNS3 is to allow for modeling of mobility for mobile

network nodes using Acumen, instead of the built-in mobility models provided in

NS-3. A class can be written in Acumen to represent movements of robots or any

physical object. During the simulation, each instance of that class will be mapped

to a network node in NS-3. The mapping is done automatically by the mobility

controller based on the configuration file which states which class in Acumen can

be used for mobility. The model in Acumen should specify the coordinates of the

physical object at the current point in time. The mobility controller will apply the

coordinates whenever a new state is present after each time step executed in Acumen.

In this manner, physical modeling can be used to model mobility of wireless nodes.

3.5.3 Accessing the State of Physical Models

Acumen provides a representation of the state of the simulation including the state

of all model instances in addition to meta-data that describe the structure of classes,

data types, class names, and book keeping of the simulation steps. The state repre-

sentation contains all instances of classes in the Acumen model, and each instance is

identified with a unique identifier. Acumen serializes all this state information into

a specific format and shares it with NS-3, which, in turn, parses the information and


extracts the information needed to recognize the progress of Acumen simulation and

the state of physical models. This state information is accessible from NS-3 scripts

and is also modifiable through the Value Store component in AcumenNS3. Accessing

any object in Acumen using the Value Store requires knowing the exact ID used to

identify the instance, i.e, the Value Store provides a lower level access to state data,

as object IDs are not known to the user from NS-3 scripts.

AcumenNS3 allows for accessing the state using a higher-level approach using a

concept we implemented called shared variables. A shared variable is an object that

can be created in the NS-3 scripts (in C++) that maps to a particular variable in

a particular object in Acumen 2 without needing to specify the internal ID of the

object that the user desires to access in Acumen. Instead of using the object ID, an

Acumen object can be identified by the node it is associated with if it is a mobility

object. Alternately, an object can be given a unique instance name stored in a

special variable in the object in order to identify the object.

From the point of view of the user of the environment, i.e., from in the NS-3

script, a shared variable is a regular C++ object but its value is mapped to a variable

in an object in Acumen. The user can retrieve or change the value from the shared

variable and the value will be updated in Acumen. Internally, the Shared Variables

Controller is responsible for synchronizing the shared variables with the most recent

state of Acumen and also updating Acumen state when the value has been changed

from the shared variable object in NS-3. Using this approach, shared variables make

manipulating the state of models seamless, the same way as manipulating a regular

variable or an object in C++, without worrying about the details of the internal

2Variables that can be accessed are the variables defined in an Acumen class, either in the class

parameters or in the private section.


structure of the value store or the mechanism and format used to exchange the state

with Acumen. An example of usage of shared variables is shown in Listing 3.1. A

detailed description and usage of shared variables is provided in Chapter 4.

Listing 3.1: Example of using shared variables.

1 DoubleSharedVariable x_prime_value("x’", "pendulum_obj"");

2 // Get and print the value

3 std::cout << x_prime_value.Get() << "\n";

4 // Assign a new value

5 x_prime_value = 10;

3.5.4 AcumenNS3 Scheduler

The co-simulation scheduler is responsible for controlling the flow of the simula-

tion and the exchange of state data between Acumen and NS-3. It is responsible

for scheduling and executing synchronization events responsible for reading Acumen

state, executing the mobility controller and the shared variables controller, and re-

porting changes to state to Acumen.

The steps that take place in a synchronization event are shown in Algorithm 1. As

seen in Algorithm 1, the synchronization event, part of the AcumenNS3 scheduler,

is responsible for receiving the state from Acumen and sending any updates back,

in addition to invoking other components. The first time the event occurs it starts

from Line 6, as the first if block (Lines 1-5) is not active in the first time. The

co-simulation starts from Line 6 where a state is received, and in Line 7, a new value

store object is constructed based on the new state in order to make it accessible to

the NS-3 script. In Line 9, the mobility controller finds all instances of models that

implement mobility behavior and map it to corresponding NS-3 nodes. The mobility


Algorithm 1: Steps of the synchronization event.

1 if not firstStep then2 new values := SharedVariablesController.GetUpdatedValues();3 update list := ConstructUpdateList(new values);4 AcumenClient.Send(update list);

5 end6 new state := AcumenClient.ReceiveNewState();7 current value store := new ValueStore(new state);8 if firstStep then9 mobility instances := MobilityController.FindMobilityInstances();

10 MobilityController.MapToNS3Nodes(mobilityInstances);

11 end12 MobilityController.ApplyMobility(current value store);13 SharedVariablesController.UpdateValues(current value store);14 ScheduleNextSyncEvent(step size);

controller knows which models to look for as it knows the name of the model class

through the first synchronization event. Then, in Line 12, the mobility controller

applies the coordinates of the mapped models to NS-3 nodes; this is done in every

synchronization event.

In Line 13, the shared variables controller updates the values of shared variables

from the current value store. Lastly, the next event is scheduled. When the next event

takes place, the first if condition (Line 1) will be enabled. Any changed values will

be collected from the variables controller, and a list of value updates will be created

and then sent to Acumen. The updates are the result of NS-3 executing since the

last event.

When Acumen attempts to receive a state information from Acumen it actually

stops execution until Acumen responds, meaning the scheduler is blocking the execu-

tion of NS-3 and is giving Acumen a chance to execute the next step. When Acumen

responds, Acumen will block its execution to allow NS-3 to catch up and execute the


current step and then respond to Acumen.

At the implementation level, and since communication between the two simulators

is done by means of network sockets, the blocking behavior is inherited naturally when

using the blocking socket API. At the mean time between synchronization events, NS-

3 will simulate network operations until the next synchronization event is due.

Chapter 4

AcumenNS3 Implementation

In the previous chapter, we showed an abstract design of AcumenNS3 components.

In this chapter, we give more detail on the implementation of AcumenNS3, for both

Acumen, and components in NS-3. At the end of the chapter, we provide an example

to demonstrate how AcumenNS3 environment can be used to create an experiment.

4.1 Acumen in Server Mode

Acumen is written in the Scala programming language and runs on the Java Virtual

Machine, which is a different platform than NS-3 which is written in C++. However,

the integration is made possible by making the two separate programs communicate

through network sockets. We extended Acumen with a “server mode” that allows

for exposing the state of the model during the simulation via network sockets. The

complete state of objects at a time step, which is known internally in Acumen as the

CStore (for Canonical Store), contains the state of the simulator and model objects at

a point in simulation time, including metadata that describe types and some internal

55

CHAPTER 4. ACUMENNS3 IMPLEMENTATION 56

simulator objects. The state basically contains a list of all objects (that is, instances

of classes defined in the Acumen model) present in the last time step executed. Each

item in the list is a serialization of the object content (variables and state) along with

the unique identifier of the object. Acumen serializes the whole state of the simulator

and models into the JavaScript Object Notation format (JSON), which is human and

machine readable [24]. When running in server mode, Acumen sends the current

CStore after executing every time step to a connected client (NS-3, in our case).

Then, before Acumen proceeds to execute the next time step, it waits for updates to

the state from the client, which is a list of variables that have been updated in NS-3.

Each item in the list contains the variable’s name, the data type of the variable, the

new value, and the object ID that the updated variable belongs to. Acumen parses

the update list and applies the changes to the state and then continues to execute

the next time step.

4.2 AcumenNS3 Components Implementation

The client side is implemented as a software library that implements the integration

components, which work on top of NS-3. NS-3 itself is a framework library that

consists of several modules, every module consists of a set of classes and models that

implement the simulator core and network models. In this work, we have extended

NS-3 with a set of classes that implements the integration interface, which include

the components listed in Section 3.3. In other words, the client side is implemented

as a library that we call AcumenNS3Lib, which cannot work on its own. In order to

perform an experiment, the user needs to write an NS-3 script code, the same way

NS-3 scripts are usually written, and this code will be linked to the AcumenNS3Lib


and NS-3 libraries, in order to form an executable program. Compiling the script and

linking it to NS-3 and the AcumenNS3Lib library is done automatically for the user,

within the AcumenNS3’s directory structure. Users of AcumenNS3 environment do

not get involved with these details as they are automated.

4.3 Acumen Models

Generally, when modeling in Acumen, model writers must define a main class that

acts as the main function in a regular imperative procedural programming language.

The job of the main class is to initiate the simulation and instantiate model objects

and initialize them with parameters. Parameters such as simulation time length, and

the size of the time step are specified in the main class. However, it makes more sense

to separate the main class from the model, meaning AcumenNS3 requires Acumen

models without a main class. The reasoning behind this is that object instantiations

and initializations are more dependent on the experiment scenario described in NS-3

scripts. Moreover, Acumen models can be written by someone other than the person

writing the NS-3 script, possibly an expert in the physical features of the system.

Thus, object instantiation and parameters can then be specified in the simulation

configuration file, which is explained in Section 4.7.1. The main class is automati-

cally generated before starting the co-simulation. This separation allows for changing

simulation parameters without needing to change Acumen models.


4.3.1 Modeling Mobility in Acumen

While Acumen model developers can specify models freely as they would in stan-

dalone Acumen. However, if the user intends to model mobility, one class should be

implemented specifically for mobility. An instance of that class will be created for

every corresponding node in NS-3. This class should be named specifically in the

simulation configuration file, along with its object initializations. Also, this class is

required to include variables that hold the current coordinates of an object (a node).

Those attributes namely are x, y, and z, and they must hold the coordinates in floating

point numbers in meters.

Listing 4.1: Modeling mobility in Acumen.

1 class Node

2 private

3 // Location coordinates

4 x := 0; y:= 0; z := 0;

5 end

6 // Model behavior details

7 ...

8 end

In the Acumen code in Listing 4.1, the mobility controller, described in Section

4.5, will map every instance of the Node class to a mobile network node in NS-3, and

coordinates will be applied automatically to network nodes during the co-simulation.

4.4 Shared Variables

Variable values in any object in Acumen can be accessed using the value store compo-

nent. Accessing any value directly from the value store requires knowing the internal

object ID at runtime. Thus, making changes to values may not be straightforward for


the user. An easier alternative is to access those values as if they are regular variables

in C++ code. Shared variables are implemented as a useful way to streamline access

to the physical state.

Shared variables are C++ objects mapped to a specific variable in an Acumen

model at runtime. In order to overcome the object ID requirement, shared variables

can map to Acumen objects in two ways. The first, if the object belongs to a class that

is associated with mobility, it can be accessed given the associated NS-3 node. The

second way, is specifying a special variable in the object to hold a specific name (an

instance name) to the instance one may need to access. All shared variable objects

created in NS-3 are automatically registered with the shared variables controller,

which ensures values are updated according to the most recent state of Acumen, and

any newly assigned values (in NS-3) are updated in Acumen as well.

Listing 4.2: Using shared variables by associated nodes.

1 DoubleSharedVariable x_prime_value("x’", my_node);

2 // Get and print the value

3 std::cout << x_prime_value.Get() << "\n";

4 // Assign a new value

5 x_prime_value = 10;

The first method is demonstrated in Listing 4.2. The variable my_node is a pointer

to an object of the type NS-3::Node. As a result, x_prime_value, will hold the

current value of the attribute x’ of that object associated with my_node at any point

in simulation time. When a new value is assigned, the shared variables controller

will ensure the value is updated in Acumen as well. Implementation-wise, in C++,

assigning new values (in the third line in 4.2) looks like assigning a fundamental

value to an object, while in reality this is made possible by overriding the assignment

operator of the DoubleSharedVariable to accept values of the type double. This


is easier and more convenient for the user to deal with shared variables almost the

same way they deal with regular variables, instead of calling a Set method to assign

values. However, a getter function1 is still required to retrieve the value, as shown in

the code listing.

The second method of accessing objects using shared variables is using their unique

instance name. In this case the Acumen model should include a specific variable

named __name__ with a string value that is unique to every instance. This value can

be assigned by the end-user in the configuration file as part of the initialization param-

eters. Code shown in Listing 4.3 demonstrates an Acumen class that instances of it

can be accessed in this manner. In the C++ code in 4.4, the DoubleSharedVariable

object will hold the value of the attribute F of the object with the attribute __name__

initialized to the string "pendulum_obj".

Listing 4.3: Defining Acumen class with a name attribute.

1 class Pendulum(x, y, z, __name__)

2 private

3 F := 0;

4 end

5 // Model behavior details

6 ...

7 end

Listing 4.4: Using shared variables by instance name.

1 DoubleSharedVariable pendulum_force("F", "pendulum_obj");

2 std::cout << pendulum_force.Get() << "\n";

3 pendulum_force = 2.56;

1In object oriented programming, a getter (and also a setter) function is used to retrieve (or set)

an internal private variable in the object. Access to the private variable is only provided through

a getter and/or a setter functions, which is a mechanism to encapsulate the internal state of the

object.


4.5 Mobility Controller

The mobility controller is an optional component that is only present when we need

to model mobility in Acumen. Any nodes that depend on an Acumen model for their

mobility should be registered with the mobility controller, which handles all aspects of

mobility of the registered nodes instead of the built-in NS-3 mobility models. The user

does not have to make all nodes mobility to be controlled by the mobility controller.

The user have the choice to include only a subset of the nodes as needed, and be

free to assign NS-3 mobility models or make some nodes stationary. The mobility

controller knows the name of the class in Acumen used for mobility and how many

instances of it will be created, from the configuration file.

4.6 The Scheduler

The task of the scheduler is to coordinate the co-simulation and invoke shared vari-

ables controller and mobility controller in order to perform their tasks. It works

according to Algorithm 1 stated in Section 3.5.4.

4.7 Configuration and Initialization

Configuration and initialization consists of several tasks that need to be done prior to

running the co-simulation. First, generating the main class for the Acumen model to

be used in the co-simulation. This step is needed for instantiating Acumen objects as

explained in Section 4.3. Second, running Acumen ahead of NS-3 to allow Acumen to

establish a server socket and listen (wait) for NS-3 connection. Settings that need to


be specified such as the port number used for the socket connection and the size of the

time step, used by both Acumen and NS-3, along with other input parameters, are

specified in a configuration file. The configuration file is described in Section 4.7.1.

These tasks are accomplished by an initialization Python script, which streamlines

the process of running the co-simulation. The Python script generates the main class

for the Acumen model based on the information provided in the configuration file

which contains all the parameters needed to instantiate classes. The script lets the

user avoid operating Acumen and NS-3 individually. To start the co-simulation,

the user simply invokes the script which is called run.py given the name of the

experiment.

4.7.1 The Configuration File

The configuration file contains three different groups of information: simulation set-

tings, object instantiations, and optional user parameters.

The simulation settings consist of the following:

• The length of the simulation time (in seconds.)

• The size of the time step.

• The port number for the underlying socket connection between Acumen and

NS-3.

The object instantiation group contains the parameters needed to instantiate Acu-

men objects. It is essential to generate the Acumen main class. Two kinds of object

instantiations can be specified: mobility objects, and general objects. For mobility

objects, the name of the class used for mobility needs to be specified. The class name


is followed by a list of lists of parameters for each single object. Object parameters

are the values that should be passed to the class, defined in the first line of a class

definition. Since mobility is optional, the mobility class name and parameters are

optional. The non-optional part is the general object instantiations which is a list of

class names and parameters that need to be passed to objects.

Optionally, the user can include any other generic parameters that may be needed

during the simulation, which can be accessed using the simulation configuration com-

ponent. This is an alternative way for specifying simulation parameters needed in

experiments, in addition to usual means such as command line arguments. The

configuration file contains all the information needed to configure and start a co-

simulation.

4.8 Setting up a Simulation

Creating an experiment requires the source directory of AcumenNS3 to be configured

to compile properly with a valid version of NS-3 in the system. That provided,

making a new experiment is straightforward. In this section, we illustrate how a

simple co-simulation experiment can be built using AcumenNS3.

A simulation experiment requires three constructs:

• An NS-3 simulation script that uses the AcumenNS3 interface,

• an Acumen model,

• and a configuration file.

A name of the experiment should be chosen to name a new directory within the

source directory of AcumenNS3. Within the directory, a configuration file and an


Acumen model file named by the exact experiment name are needed, along with

one or more C++ source files for the NS-3 script. These files can be automatically

generated using a helper script.

4.8.1 Example Experiment Scenario

The experiment used for this example is a demonstration of modeling a simple motion

of an object in Acumen and how to control its state from NS-3. The scenario is a

single object that moves in a single direction. The movement can be in one of four

different states: still, accelerating, decelerating, and moving at a constant speed.

Initially, the object is still in an initial location. In the NS-3 side for the simulation,

the state can be controlled using a shared variable. Also the mobility of the moving

object is reflected in NS-3. This example is trivial as the goal here is to demonstrate

how the environment can be used. Below, we list the code of the three components

of this example.


The Acumen Model

Listing 4.5: A simple Acumen model.

1 class Node(x, y, a)

2 private

3 x’ := 0; x’’ := 0; state := "Still"

4 end

5 switch state

6 case "Accelerating"

7 x’’ = a;

8 case "Constant"

9 x’’ = 0;

10 case "Decelerating"

11 x’’ = -a;

12 if (x’ < 0)

13 state := "Still";

14 end;

15 case "Still"

16 x’’ = 0;

17 x’ = 0;

18 end

19 end

The only class in this model takes three input parameters:

• The coordinate in the x axis,

• The coordinate in the y axis, which will be set to a constant just to comply

with AcumenNS3 mobility controller requirements,

• and the acceleration value.

These class parameters are specified in the configuration file as will be seen in the

next subsection. In the private section of the class definition (Lines 2-4), we have the

first and second derivatives of x which represents the position in the x axis. Assigning

velocity to x’ or acceleration to x’’ (Lines 7, 9, 11) allows Acumen to determine the


position x automatically as time advances. Each instance of this class will be mapped

to a node in NS-3.

The Configuration File

Listing 4.6: The configuration file for the simple experiment.

1 {

2 "SimulationTime": 10.0,

3 "AcumenPortNumber": 2345,

45 "Mobility": true ,

6 "NodesCount": 1,

7 "ClassName": "Node",

89 "MobilityParameters": [

10 [0, 100, 2] // Node class arguments

11 // Other instances go here if needed: ,[0, 200, 3]

12 ],

1314 "ModelParameters": [

15 ]

16 }

The configuration file states a simulation of 10 seconds (Line 2). Mobility is

switched on (Line 5) for a single node (Line 6) which will be associated with an

instance of the class Node (stated in Line 7). Since we only have one mobile node, we

have a single instantiation which is stated in the MobilityParameters option (Lines

9-12). The values are for the three parameters of the Node object in the same order.

The ModelParameters option (Line 14) used for general instantiations is empty since

we do not need any other objects than the object used for mobility. However, general

objects can be specified similar to mobility instantiations but parameters are preceded

by the class name. For example, if we want to instantiate a class named SomeClass


with three parameters we can write: ["SomeClass", 10, 0, 20].


NS-3 Simulation Script

Listing 4.7: C++ code for the NS-3 script.

1 #include "acumen -ns3.h"

2 using namespace ns3;

34 void AccelerateNode(StringSharedVariable state)

5 {

6 state = "Accelerating";

7 }

89 void MoveInConstantSpeed(StringSharedVariable state)

10 {

11 state = "Constant";

12 }

1314 void DeccelerateNode(StringSharedVariable state)

15 {

16 state = "Decelerating";

17 }

1819 int main(int argc , char *argv [])

20 {

21 std:: string configFile;

2223 CommandLine commandLine;

24 commandLine.AddValue("config -file", "Name of configuration

file", configFile);

25 commandLine.Parse(argc , argv);

2627 NodeContainer nodes;

28 nodes.Create (1); // Create one node

2930 SimulationConfig *config = SimulationConfig ::

CreateFromConfigFile(configFile);

31 MobilityController mobilityController(config);

32 mobilityController.InstallMobility(nodes);

33 AcumenNs3Scheduler scheduler(config , &mobilityController);

34 scheduler.Init();

3536 StringSharedVariable state("state", nodes.Get (0));


37 Simulator :: Schedule(Seconds (2), &AccelerateNode , state);

38 Simulator :: Schedule(Seconds (5), &MoveInConstantSpeed , state)

;

39 Simulator :: Schedule(Seconds (8), &DeccelerateNode , state);

4041 DoubleSharedVariable velocity("x’", nodes.Get (0));

42 AcumenValuePlotter plotter("Velocity of the node", "Time", "

Velocity");

43 plotter.AddVariable (&velocity , "x’");

4445 scheduler.Run();

4647 plotter.GenerateOutput ();

4849 delete config;

50 return 0;

51 }

The NS-3 C++ code shown in Listing 4.7 shows how to write an NS-3 simulation

code with co-simulation. It is similar to writing code for standalone NS-3. It shows

how to use shared variables to access and change the state of a value in an Acumen

object. For this example, three callbacks are scheduled at different times to change

the value of the “state” variable of the Node object (Lines 37-29). The callbacks are:

AccelerateNode (Line 4), DecelerateNode (Line 14), and MoveInConstantSpeed

(Line 9), which set the state variable accordingly.

In Listing 4.7, we demonstrate how to apply Acumen mobility on a node using the

MobilityController. Its method, InstallMobility (Line 32), will map all nodes

in the node container to an instance of the class assigned for mobility.

A useful class, shown in Listing 4.7, is the AcumenValuePlotter (Line 42), which

is a helper class that monitors the value of a given shared variable over the simulation

time and produces a graph at the end of the simulation.

Chapter 5

Evaluation

In this chapter, we demonstrate a number of experiments conducted using the Acu-

menNS3 interface. We show the results of those experiments and, when possible

compare them with version implemented solely in NS-3. Results include the bench-

marks of running the co-simulation in different settings. In each following section

we describe an experiment scenario, the Acumen model used, and what the NS-3

script does, and show simulation results with some analysis. At the end of the chap-

ter, we provide additional discussion about the performance and usefulness of the

environment.

5.1 Simulation Setup

The machine on which we ran experiments is equipped with Intel Core i5 2.7 GHz

and 12 GB of RAM and Mac OS X (10.8) operating system. As Acumen depends on

the Java Runtime Environment (JRE), we used the OS X version of JRE 1.6 (Java 6)

Update 65. Along with NS-3 version 3.16. The Acumen source code that we modified

70

CHAPTER 5. EVALUATION 71

to add server mode was obtained from Acumen source repository in April 2013.

For performance evaluation, we measure the CPU time of each process of Acu-

menNS3 (both Acumen process and NS-3 process). The CPU time is the time spent

executing the simulation in each process. The time when the measured program is

waiting for its scheduled CPU time, sleeping or waiting on a socket (blocked) is not

included as the process is not consuming any CPU time. The sum of the CPU times

of both processes represents the overall CPU time of AcumenNS3.

Although we ran the experiments on a multi-core processor, both Acumen1 and

NS-3 are single threaded. When either process is running, the other process is in a

blocked state, except when the two processes are communicating (when sending and

receiving), so multiple cores were utilized by the system.

5.2 Leader-Follower Scenario

A lead-follow behavior between two mobile robots connected via a wireless link is

modeled. The leader node speed is fixed, while the follower node starts at a lower

speed then accelerates whenever the leader is sensed to be out of range by not re-

ceiving periodically sent beacons. Once the follower node receives a sufficient number

of beacons to consider itself “connected”, it decelerates to its original speed. The

Acumen model shown in Listing 5.1 captures the motion of the leader and follower

robots through four motion states: Accelerating, Decelerating, Constant speed, or

Still state. Each instance of the Node class is mapped to an NS-3 node. The simu-

lation is 80 seconds long. The network model used is WiFi 802.11b in ad hoc mode,

1Acumen implements several interpreters for its language including a parallel one. The reference

interpreter was used which is sequential.


with a full Internet Protocol stack with the Ad hoc On-Demand Distance Vector

(AODV) routing and the User Datagram Protocol (UDP) as the transport protocol.

Listing 5.1: Acumen model for lead-follow.

1 class Node(x, x’, x’’, y, accel , state)

2 private

3 init_v := x’;

4 end

5 switch state

6 case "Accelerating"

7 x’’ = accel;

8 case "Constant"

9 x’’ = 0;

10 case "Decelerating"

11 x’’ = -accel;

12 if (x’ <= init_v)

13 state := "Constant ";

14 end;

15 case "Still"

16 x’’ = 0;

17 x’ = 0;

18 end

19 end

Note that dynamic state change is needed to determine whether the follower is

in the transmission range of the leader. This control part is implemented in the NS-

3 script which uses the co-simulation interface to access the physical state. When

the follower node does not receive any packets from the leader for two seconds, the

follower controller will order the node to accelerate by changing the value of thestate

variable. The interface will recognize the change and send the updated value back to

Acumen. In this case the state of the node will change to “Accelerating” in Acumen

and this will result in the node to accelerate. For comparison, the same experiment

was also implemented in NS-3 only (standalone) using built-in mobility models to

represent motion.


5.2.1 Results

0

20

40

60

80

100

120

140

160

0 10 20 30 40 50 60 70 80

Simulation time (s)

Leader speed (m/s)Follower speed (m/s)

Distance between nodes (m)

Figure 5.1: Simulation results for lead-follow using standalone NS-3 with 0.01 s sam-pling.


0

20

40

60

80

100

120

140

160

180

0 10 20 30 40 50 60 70 80

Simulation time (s)



Figure 5.2: Simulation results for lead-follow using standalone NS-3 with 0.2 s sam-pling.

0

20

40

60

80

100

120

140

160

180

200

0 10 20 30 40 50 60 70 80

Simulation time (s)



Figure 5.3: Simulation results for lead-follow using standalone NS-3 with 1 s sampling.


0

20

40

60

80

100

120

140

160

0 10 20 30 40 50 60 70 80

Simulation time(s)



Figure 5.4: Simulation results for lead-follow using AcumenNS3.

Figures 5.1, 5.2, 5.3 and 5.4 show how the follower accelerates and decelerates, and

how the distance between nodes changes over time. Table 5.1 shows the results

of running both standalone simulations (with different sampling times) and the co-

simulation. Sampling time in standalone simulations refers to the frequency of sched-

uled events that control the motion. There is no need to specify the sampling in

Acumen, as the default simulation step size is 0.01 seconds. In addition, CPU time

is shown for each type of simulation.


Table 5.1: CPU times for the lead-followsimulations.

Experiment Sampling CPU timea

Standalone NS-3

0.01 0.3940.1 0.3950.2 0.3831.0 0.384

AcumenNS3 Default (0.01) (8.66+4.70) 13.36a CPU time is the sum of CPU times of Acumen and

NS-3, listed in the same order in the table. This doesnot apply to CPU times of standalone NS-3.

Figure 5.5: Simulation field for lead-follow with variable terrain.

Since the physical model is separated from the network model, we can make

changes to the physical model without requiring changes to the code that accesses the

physical state from NS-3, unless we need to access different variables. In a modified

version of this experiment, we introduced varying terrain characteristics to the phys-

ical model, meaning that nodes speeds change as they encounter a different terrain,


as depicted in Figure 5.5. This was done in the Acumen model by using different

friction coefficient values. No changes to the NS-3 script were required for this to

work. For the sake of variance from the original scenario, we made another variant

where the follower node controller depends on the Received Signal Strength (RSS) of

the wireless link for sensing how far it is from the leader node. Figure 5.6 and 5.7

shows the motion behavior and distance of this scenario. CPU times are shown in

Table 5.2.

-20

0

20

40

60

80

100

120

140

160

0 10 20 30 40 50 60 70 80

Simulation time(s)



Figure 5.6: Simulation results for lead-follow with variable terrain using AcumenNS3.


-20

0

20

40

60

80

100

120

140

0 10 20 30 40 50 60 70 80

Simulation time(s)



Figure 5.7: Simulation results for lead-follow with RSS and variable terrain usingAcumenNS3.

Table 5.2: CPU times for the lead-follow simulations with additional features.

Experiment Sampling CPU timeAcumenNS3 (terrain) Default (0.01) (8.92+4.62) 13.54

AcumenNS3 (RSS and terrain) Default (0.01) (8.57+3.89) 12.46

5.2.2 Analysis

Implementing the lead-follow behavior solely in standalone NS-3 in a discrete-event

simulator introduces slight differences in the produced behavior. The differences are

dependent on how the physical continuous phenomena is implemented, especially the

sampling frequency of events that control the motion. As we change the sampling,

the resulting behavior changes as well. While the variance seems slight, we can expect

serious variations in the results of more sophisticated scenarios.


While the use of a short inter-sampling duration (0.01 seconds) in the NS-3 stan-

dalone version seems to yield accurate results (as the graph is almost identical to that

of AcumenNS3), it also yields a small CPU time. Nevertheless, higher (but tolerable)

CPU times by using AcumenNS3 can be acceptable, since we have a specialized tool

for modeling the physical aspects, and utilize the modeling capability of Acumen.

Modeling the physical mobility behavior in standalone NS-3 involves using built-in

mobility models (such as the constant acceleration model) and setting its parameters

at different points in the simulation. Introducing complexity to the physical behavior

such as the varying terrain can be cumbersome to implement in this manner, in such

case, using Acumen to model the mobility is more convenient for the modeler.

A more complex scenario was evaluated (Varied terrain and RSS). As shown in

Figures 5.6 and 5.7), a different behavior is produced as we tune the physical model

only (Figure 5.6). The advantage here is the ability to change the physical model

freely, as it is separated from the network model in NS-3. As well, another behavior

was also introduced when we add RSS to the network model (Figure 5.7).

There was almost no increase in CPU time as seen in Table 5.2 as we add more

features to both models. Also, it can be seen for all versions of the AcumenNS3

experiments, that Acumen is the most demanding for CPU power.

5.3 Controlled Inverted Pendulum

This experiment involves an inverted pendulum over a cart, as shown in Figure 5.8.

The inverted pendulum is an example of a balanced system, which is a mechanical

system that stabilizes a center of mass over a pivot point. Examples of balance

systems include the Segway personal transporter (previously mentioned in Section


2.1) and gimbaled nozzles used to balance rockets [3].

Figure 5.8: The inverted pendulum.

In this example, the inverted pendulum is a ball attached to a pole over a cart

(Figure 5.8). The cart is a mobile node, and we will call this node the pendulum

node. The pendulum node is able to move in order to keep the pendulum in an

upright position. In order to do that, it needs to send several measurements of the

pendulum state to a controller node, which calculates the force required to accelerate

the cart (the pendulum node). The pendulum node sends the measurements every

0.1 seconds, and the controller node sends the response back immediately over the

network. We ran the simulation for 15 seconds of simulation time.

Two variants of this experiment were implemented: one with the controller and

pendulum nodes connected using a point-to-point link with multiple delays, while the


other with the nodes connected using a wireless link. The point-to-point link between

the controller and pendulum nodes is equivalent to a serial link with a simple NS-3

implementation of the Point-to-Point Protocol (PPP) 2. The wireless link uses the

same 802.11b network model as the previous experiment. Both versions use the same

Internet Protocol stack with the Transmission Control Protocol (TCP) for packet

transport.

x′′ =F −m× l × (cos(θ) × θ′′ − (θ′)2 × sin(θ))

M +m(5.1)

θ′′ =θ′′ = x′ × sin(θ) × θ′ +G× sin(θ) − x′′ × cos(θ)

l(5.2)

F = 64.0348 × θ + x+ 4.036673 × x′ + 19.7313 × θ′ (5.3)

The pendulum is described using equations 5.1, 5.2, where M is the mass of the

cart, m is the mass of the ball, l is the length of the pole, and F is the force which

is computed using 5.3, where x is the position of the cart, and x′, x′′ are the speed

and acceleration of the cart as the first and second derivatives of x respectively,

while θ is the angle of the pendulum, and θ′ and θ′′ are the angular speed and

angular acceleration. Equation 5.3 is the controller that computes F for 0 delay.

F is computed by the controller node in NS-3 after receiving the measurements of x,

x′, and θ′.

Listing 5.2 shows the Acumen model for this experiment. Two instances of the

2For details about the point-to-point implementation in NS-3: http://www.nsnam.org/docs/

release/3.18/models/html/point-to-point.html. Accessed: 30/01/2014

http://www.nsnam.org/docs/release/3.18/models/html/point-to-point.html

http://www.nsnam.org/docs/release/3.18/models/html/point-to-point.html


Node class will be mapped to two NS-3 nodes. If the role variable is initialized with

the value "Pendulum" in one instance it will be considered as the pendulum node and

it will create an InvertedPendulum object.

The control part is realized by controller objects associated with each node, imple-

mented in the NS-3 script of this experiment. The pendulum node is associated with

a controller that reads the measurements from the pendulum object (from Acumen

using shared variables), and then packetizes the measurements into a TCP packet in

order to be sent to the controller node. The controller node is also associated with a

controller as well, which is responsible for calculating the force F once measurements

are received from the pendulum node. The calculated value is put into a TCP packet

and sent to the pendulum nodes. The pendulum node controller receives this packet

and sets the corresponding F variable in the physical pendulum model to the received

value. This will lead to applying the calculated force to the cart which will move ac-

cordingly. The corresponding node in NS-3 will move as well due to the mapping

between the nodes and the Acumen model. The simulation length is 15 seconds long.


Listing 5.2: Acumen model for the inverted pendulum.

1 class Node(x, y, z, role)

2 private

3 pendulum := 0;

4 mode := "Init";

5 end

6 switch mode

7 case "Init"

8 if role == "Pendulum"

9 pendulum := create InvertedPendulum("pendulum_obj");

10 end;

11 mode := "Persist"

12 case "Persist"

13 if role == "Pendulum"

14 x = pendulum.x

15 end;

16 end

17 end

1819 class InvertedPendulum(__name__)

20 private

21 M := 1; m := 1; l := 1;

22 G := 9.8; p := [0,0,0];

23 x := 0; x’ := 0; x’’ := 0;

24 theta := 0.3; theta ’ := 0; theta ’’ := 0;

25 F := 0; Pi := 3.1415926;

26 end

2728 x’’ = (F - m*l*(cos(theta)*theta ’’ - (theta ’)^2*sin(theta)))

/(M+m);

29 theta ’’ = (x’*sin(theta)*theta ’ + G*sin(theta) - x’’*cos(

theta))/l;

30 end

5.3.1 Results

Figures 5.9, 5.10 and 5.11 show the graphs of the pendulum variables over time for

the experiment with the wired link and varied delay. The effect of delay on how the

pendulum stabilizes can be seen from the graphs. Figure 5.12 shows the pendulum


for the wireless version of the experiment. CPU times are shown in Table 5.3.

-10

0

10

20

30

40

0 2 4 6 8 10 12 14

Time

inverted-pendulum

thetatheta’

xx’F

Figure 5.9: Simulation results of the inverted pendulum with 2 ms delay (point-to-point controller).


-20

-10

0

10

20

30

40

0 2 4 6 8 10 12 14

Time

inverted-pendulum

thetatheta’

xx’F


-40

-30

-20

-10

0

10

20

30

40

0 2 4 6 8 10 12 14

Time

inverted-pendulum

thetatheta’

xx’F



-10

0

10

20

30

40

0 2 4 6 8 10 12 14

Time

inverted-pendulum

thetatheta’

xx’F

Figure 5.12: Simulation results of the inverted pendulum using a wirelessly connectedcontroller.

Table 5.3: CPU times for the inverted pendulum simulations.

Link Delay (ms) CPU time

Point-to-point link2 (3.46+1.62) 5.085 (3.45+1.61) 5.0610 (3.46+1.61) 5.07

Wireless link n/a (3.65+2.13) 5.78

5.3.2 Analysis

In the figures above, the controller for zero-delay (i.e., where the controller and the

pendulum are directly connected) was instead connected to the pendulum over links

of variable delays, in addition to a wireless link. The changes applied between the


different scenarios were minimal, and only involved changing the link parameters in

the network simulator. The specifications of both the controller and the cart were

not changed.

As the results show, the response for the delayed link required the application

of a more variable source in order to achieve convergence to θ = 0. This response

is inevitable given that θ measurements arrive at the zero-delay controller after a

non-zero-delay, which prolongs the convergence process.

The CPU time measurements indicate a somewhat uniform simulation perfor-

mance for the tested scenarios. Additional processing is expected in the wireless case

due to additional packetization delays.

This experiment is an example of a scenario that usually cannot be implemented

only in NS-3. The reason is, the equations that describe the pendulum need to be

solved in continuous time. This cannot be done easily in standalone NS-3 without

using special mathematical libraries. Modeling the pendulum in Acumen, given the

provided equations, was not only straightforward, but also with a few extra lines of

code, we get a visual 3D model of the pendulum in the Acumen GUI 3. Extending

this scenario to a more sophisticated network scenario, e.g. a multi-link network, with

links shared with other traffic types, can be also be achieved with ease.

5.4 Remarks

The reason for the significant performance increase while using AcumenNS3 is mainly

due to running two processes side by side and exchanging information at runtime.

3Acumen GUI is not enabled by default when used in AcumenNS3. It still can be enabled

optionally by the user but it will affect CPU time.


This introduces additional overhead especially during synchronization events where

tasks such as parsing state representation, maintaining mobility and shared variables

take place.

CPU resources required for the implemented simulations vary between NS-3 and

Acumen. As can be seen from the benchmarks in this chapter, Acumen is more de-

manding for CPU resources than NS-3. One of the reasons is the overhead required by

the JRE. The majority of the overhead is resulted from parsing state updates coming

from NS-3. Part of the overhead resulted from serializing the complete Acumen state

after every time step in the simulation. The serialization requires traversing Acu-

men objects and producing JSON representations which also requires heavy string

manipulation. The most significant cause of additional overhead in Acumen is JSON

processing and state serialization which takes about 70% of CPU time consumed by

Acumen for the leader follower scenario, and about 60% for the inverted pendulum

experiment.

NS-3 CPU time as well experienced some significant overhead compared to stan-

dalone simulations which can execute in about less than half a second of CPU time

(the lead and follow scenario). The increased overhead was a result of parsing the com-

plete JSON representation of Acumen state after every time step executed. JSON

parsing alone consumed about 58% of NS-3 CPU time in lead follow scenario and

about 64% in the inverted pendulum. This significant overhead was due to using an

inefficient JSON library.

The components of AcumenNS3, especially in NS-3, does not cause a great deal

of overhead. If a more efficient technique was used to handle state processing, we

can reduce the CPU time significantly. For instance, we can limit Acumen state


exchanged to only the variables needed by NS-3. Lastly, we expect that CPU time

can be reduced through certain optimizations in the implementations. We also intend

to test the scalability of our environment with more complex experiments.

Chapter 6

Conclusion and Future Work

6.1 Conclusion

In this thesis we have proposed a co-simulation environment for modeling and sim-

ulating networked CPSs. The environment is called AcumenNS3, which integrates

Acumen to NS-3, adding physical modeling capabilities to network modeling in NS-3.

This integration allows for more realistic and easier modeling of physical features that

are continuous in nature, but have been modeled as discrete-event processes within

network simulators which are discrete-event-based. With AcumenNS3, NS-3 can de-

pend on Acumen for mobility modeling, instead of included discrete-based mobility

models. This approach in mobility generates realistic movements of nodes as it is

the result of the physical aspects of the system and environment as an alternative

to preprogrammed or random movements. This benefits network modelers as the

reliability of simulation is improved results closer to reality should be achieved, since

network simulation results are affected by mobility behavior.

90

CHAPTER 6. CONCLUSION AND FUTURE WORK 91

We have presented the design of AcumenNS3 and how the integration is accom-

plished. Acumen was extended to provide access to its state during the simulation in

a format understandable by AcumenNS3. AcumenNS3 implements a co-simulation

engine and other components that work on top NS-3’s framework to support the

synchronization of physical model state. AcumenNS3 also manges mobility for NS-3

through automatic mapping between nodes and corresponding Acumen models that

provide movements. As well, general access to the physical state is provided through

shared variables, which are C++ objects mapped to variables in Acumen objects.

Additional physical phenomena other than mobility can be modeled in Acumen

to utilize equation solving, as we have demonstrated the inverted pendulum example.

This ability can be employed to model more complex physical objects such as robotics,

vehicles and many others, allowing a wider range of experiments for applications such

as networked robotics and vehicular networks and other CPS applications.

6.2 Future Work

More complex experiments need to be implemented to further show the combined

modeling capability of our integrated environment. For instance, a detailed model of

a mechanical robot using rigid body dynamics for example can be written in Acumen

as part of a robotic experiment. Additionally, scenarios with a large number of nodes

with more complex network configurations and more detailed physical models allow

us to test the scalability and performance of the environment.

An example of other physical aspects that can be modeled in Acumen is energy

consumption. Energy consumption is a key factor in the performance of wireless

communication devices and Wireless Sensor Networks (WSN). There are different


types of battery models that describe the battery processes in detail depending on

the type of the battery [23], based on models of electrochemical processes or electrical

circuits in addition to some analytical models. It is possible to utilize Acumen to

incorporate such models into the energy model structure introduced recently in NS-3.

Models in Acumen can be compared with those available in NS-3 for evaluating the

influence of energy consumption on the performance of the CPS.

We plan on making more enhancements and optimizations especially in regards

to modeling ability and simulation performance. For instance, currently AcumenNS3

allows only one Acumen class to be chosen for mobility. As many objects as possible

can be mapped to network nodes to dictate movements. The behavior of the class

will apply to all mapped nodes. It is possible for the Acumen class to produce

several behaviors depending on an internal state variable, but if the user requires

more behaviors for different nodes or groups of nodes, then the Acumen class can

be complex. A possible solution is to allow several Acumen classes to be mapped to

different nodes in NS-3, and that would allow each class to have a specific behavior,

and eliminate the need for one complex class.

In the current implementation, a shared variable maps to a single variable in an

object in Acumen. If access to multiple variables in the same object is needed, then

multiple shared variables need to be created in order to access that objects’ variables

in Acumen. While that is not necessarily a disadvantage, it might be useful for users

to have shared objects (instead of variables) which can be mapped to a whole object

in Acumen. This would allow users to access variables using a syntax similar to

object.variable.

As for performance, optimizations are possible in the current implementation,


especially the scheduler component and serialization/deserialization of Acumen state.

Another possible future direction is implementing standard higher level interfaces

such as the Functional Mock-up Interface (FMI) [6]. FMI provides a mechanism

for interfacing two simulators through a standardized interface. FMI facilitate both

model exchange and co-simulation. A possible direction, is adding FMI support to

NS-3, as this will allow integrating NS-3 with a different physical modeling tool that

support the FMI standard.

A possible enhancement is introducing a graphical user interface that supports

constructing NS-3 and Acumen models. We also plan on making AcumenNS3 avail-

able for the networking research community at large which could generate valuable

feedback to further improve AcumenNS3.

Bibliography

[1] Acumen tutorials. Accessed: 03/12/2013. URL: http://www.

acumen-language.org/p/tutorials.html.

[2] Ahmad T Al-Hammouri, Michael S Branicky, and Vincenzo Liberatore. Co-

simulation tools for networked control systems. In Hybrid Systems: Computation

and Control, pages 16–29. Springer, 2008.

[3] Karl Johan Astrom and Richard M Murray. Feedback systems: an introduction

for scientists and engineers. Princeton university press, 2010.

[4] Christian Bettstetter. Smooth is better than sharp: a random mobility model

for simulation of wireless networks. In Proceedings of the 4th ACM international

workshop on Modeling, analysis and simulation of wireless and mobile systems,

MSWIM ’01, pages 19–27, New York, NY, USA, 2001. ACM. URL: http:

//doi.acm.org/10.1145/381591.381600, doi:10.1145/381591.381600.

[5] Bleex - berkeley robotics and human engineering laboratory. Accessed:

15/12/2013. URL: http://bleex.me.berkeley.edu/research/exoskeleton/

bleex/.

94

http://www.acumen-language.org/p/tutorials.html

http://www.acumen-language.org/p/tutorials.html

http://doi.acm.org/10.1145/381591.381600

http://doi.acm.org/10.1145/381591.381600

http://dx.doi.org/10.1145/381591.381600

http://bleex.me.berkeley.edu/research/exoskeleton/bleex/

http://bleex.me.berkeley.edu/research/exoskeleton/bleex/

BIBLIOGRAPHY 95

[6] Torsten Blochwitz, Martin Otter, Johan Akesson, Martin Arnold, Christoph

Clauss, Hilding Elmqvist, Markus Friedrich, Andreas Junghanns, Jakob Mauss,

Dietmar Neumerkel, et al. Functional mockup interface 2.0: The standard for

tool independent exchange of simulation models. In 9th International Modelica

Conference, Munich, 2012.

[7] Tracy Camp, Jeff Boleng, and Vanessa Davies. A survey of mobility models

for ad hoc network research. Wireless Communications and Mobile Computing,

2(5):483–502, 2002.

[8] A. Cervin, D. Henriksson, B. Lincoln, J. Eker, and K. Arzen. How does control

timing affect performance? analysis and simulation of timing using jitterbug and

truetime. Control Systems, IEEE, 23(3):16–30, 2003. doi:10.1109/MCS.2003.

1200240.

[9] National science foundation announces projects to expand the frontiers of cyber-

physical systems. Accessed: 14/11/2013. URL: http://www.isis.vanderbilt.

edu/node/4568.

[10] Nsf funds cyber-physical systems project. Accessed: 14/11/2013. URL: http:

//news.nd.edu/news/17248-nsf-funds-cyber-physical-systems-project.

[11] V. A. Davies. Evaluating mobility models within an ad hoc network. Master’s

thesis, Colorado School of Mines, 2000.

[12] J Davis II, Mudit Goel, Chirstopher Hylands, Bart Kienhuis, Edward A Lee,

Jie Liu, Xiaojun Liu, Lukito Muliadi, Steve Neuendorffer, John Reekie, et al.

http://dx.doi.org/10.1109/MCS.2003.1200240

http://dx.doi.org/10.1109/MCS.2003.1200240

http://www.isis.vanderbilt.edu/node/4568

http://www.isis.vanderbilt.edu/node/4568

http://news.nd.edu/news/17248-nsf-funds-cyber-physical-systems-project

http://news.nd.edu/news/17248-nsf-funds-cyber-physical-systems-project

BIBLIOGRAPHY 96

Overview of the ptolemy project. Technical report, ERL Technical Report

UCB/ERL, 1999.

[13] P. Derler, E.A. Lee, and A.-S. Vincentelli. Modeling cyber physical systems. Pro-

ceedings of the IEEE, 100(1):13–28, 2012. doi:10.1109/JPROC.2011.2160929.

[14] F. Dressler, C. Sommer, D. Eckhoff, and O.K. Tonguz. Toward realistic sim-

ulation of intervehicle communication. IEEE Vehicular Technology Magazine,

6(3):43 –51, sept. 2011. doi:10.1109/MVT.2011.941898.

[15] Emeka Eyisi, Jia Bai, Derek Riley, Jiannian Weng, Wei Yan, Yuan Xue, Xenofon

Koutsoukos, and Janos Sztipanovits. NCSWT: An integrated modeling and

simulation tool for networked control systems. Simulation Modelling Practice and

Theory, 27(0):90 – 111, 2012. URL: http://www.sciencedirect.com/science/

article/pii/S1569190X12000688, doi:10.1016/j.simpat.2012.05.004.

[16] J. Fink, A. Ribeiro, and V. Kumar. Robust control for mobility and wireless com-

munication in cyber-physical systems with application to robot teams. Proceed-

ings of the IEEE, 100(1):164–178, 2012. doi:10.1109/JPROC.2011.2161427.

[17] GloMoSim. Accessed: 14/01/2013. URL: http://pcl.cs.ucla.edu/projects/

glomosim.

[18] J. Gozalvez, S. Turksma, L. Lan, O. Lazaro, F. Cartolano, E. Robert, D. Kra-

jzewicz, R. Bauza, F. Filali, M. Rockl, et al. iTETRIS: the framework for large-

scale research on the impact of cooperative wireless vehicular communications

systems in traffic efficiency. In Information and Communications Technologies

(ICT-MobileSubmit 2009), 2009.

http://dx.doi.org/10.1109/JPROC.2011.2160929

http://dx.doi.org/10.1109/MVT.2011.941898

http://www.sciencedirect.com/science/article/pii/S1569190X12000688

http://www.sciencedirect.com/science/article/pii/S1569190X12000688

http://dx.doi.org/10.1016/j.simpat.2012.05.004


http://pcl.cs.ucla.edu/projects/glomosim

http://pcl.cs.ucla.edu/projects/glomosim

BIBLIOGRAPHY 97

[19] M.S. Hasan, H. Yu, A. Carrington, and T.-C. Yang. Co-simulation of wireless

networked control systems over mobile ad hoc network using SIMULINK and

OPNET. Communications, IET, 3(8):1297–1310, 2009. doi:10.1049/iet-com.

2008.0536.

[20] Xiaoyan Hong, Mario Gerla, Guangyu Pei, and Ching-Chuan Chiang. A group

mobility model for ad hoc wireless networks. In Proceedings of the 2nd ACM

international workshop on Modeling, analysis and simulation of wireless and

mobile systems, MSWiM ’99, pages 53–60, New York, NY, USA, 1999. ACM.

URL: http://doi.acm.org/10.1145/313237.313248, doi:10.1145/313237.

313248.

[21] Amit Jardosh, Elizabeth M. Belding-Royer, Kevin C. Almeroth, and Subhash

Suri. Towards realistic mobility models for mobile ad hoc networks. In Proceed-

ings of the 9th annual international conference on Mobile computing and network-

ing, MobiCom ’03, pages 217–229, New York, NY, USA, 2003. ACM. URL: http:

//doi.acm.org/10.1145/938985.939008, doi:10.1145/938985.939008.

[22] J. Jobin, M. Faloutsos, S.K. Tripathi, and S.V. Krishnamurthy. Understanding

the effects of hotspots in wireless cellular networks. In Twenty-third Annual Joint

Conference of the IEEE Computer and Communications Societies, volume 1,

pages 4 vol. (xxxv+2866), march 2004. doi:10.1109/INFCOM.2004.1354537.

[23] Marijn R Jongerden and Boudewijn R Haverkort. Which battery model to use?

Software, IET, 3(6):445–457, 2009.

[24] Introducing JSON. Accessed: 14/11/2013. URL: http://www.json.org.

http://dx.doi.org/10.1049/iet-com.2008.0536

http://dx.doi.org/10.1049/iet-com.2008.0536

http://doi.acm.org/10.1145/313237.313248

http://dx.doi.org/10.1145/313237.313248

http://dx.doi.org/10.1145/313237.313248

http://doi.acm.org/10.1145/938985.939008

http://doi.acm.org/10.1145/938985.939008

http://dx.doi.org/10.1145/938985.939008

http://dx.doi.org/10.1109/INFCOM.2004.1354537

http://www.json.org

BIBLIOGRAPHY 98

[25] Kyoung-Dae Kim and P.R. Kumar. Cyber-physical systems: A perspective at the

centennial. Proceedings of the IEEE, 100(Special Centennial Issue):1287–1308,

2012. doi:10.1109/JPROC.2012.2189792.

[26] T. Kohtamaki, M. Pohjola, J. Brand, and L.M. Eriksson. Piccsim toolchain -

design, simulation and automatic implementation of wireless networked control

systems. In Networking, Sensing and Control, 2009. ICNSC ’09. International

Conference on, pages 49–54, 2009. doi:10.1109/ICNSC.2009.4919244.

[27] D. Krajzewicz, G. Hertkorn, C. Rossel, and P. Wagner. Sumo (simulation of

urban mobility). In Proceedings of the 4th Middle East Symposium on Simulation

and Modelling, pages 183–187, 2002.

[28] Michal Kudelski, Luca M. Gambardella, and Gianni A. Di Caro. Robonet-

sim: An integrated framework for multi-robot and network simulation.

Robotics and Autonomous Systems, 61(5):483 – 496, 2013. URL: http:

//www.sciencedirect.com/science/article/pii/S0921889013000080, doi:

http://dx.doi.org/10.1016/j.robot.2013.01.003.

[29] ThomasHalva Labella, Isabel Dietrich, and Falko Dressler. Hybrid simulation of

sensor and actor networks with baraka. Wireless Networks, 16:1525–1539, 2010.

[30] B. Liang and Z.J. Haas. Predictive distance-based mobility management for pcs

networks. In Eighteenth Annual Joint Conference of the IEEE Computer and

Communications Societies, volume 3, pages 1377 –1384 vol.3, mar 1999.

[31] Sven Erik Mattsson, Hilding Elmqvist, and Martin Otter. Physical sys-

tem modeling with modelica. Control Engineering Practice, 6(4):501


http://dx.doi.org/10.1109/ICNSC.2009.4919244

http://www.sciencedirect.com/science/article/pii/S0921889013000080


http://dx.doi.org/http://dx.doi.org/10.1016/j.robot.2013.01.003

http://dx.doi.org/http://dx.doi.org/10.1016/j.robot.2013.01.003

BIBLIOGRAPHY 99

– 510, 1998. URL: http://www.sciencedirect.com/science/article/

pii/S0967066198000471, doi:http://dx.doi.org/10.1016/S0967-0661(98)

00047-1.

[32] Aarathi Muppalla and B. S. Manoj. The impact of communication and ter-

rain characteristics on the accuracy of robot formation. In Proceedings of the

1st International Conference on Wireless Technologies for Humanitarian Relief,

ACWR ’11, pages 497–502, New York, NY, USA, 2011. ACM. URL: http:

//doi.acm.org/10.1145/2185216.2185342, doi:10.1145/2185216.2185342.

[33] The network simulator - ns-2. Accessed: 14/01/2013. URL: http://www.isi.

edu/nsnam/ns.

[34] ns-3. Accessed: 14/01/2013. URL: http://www.nsnam.org.

[35] Open Dynamics Engine. Accessed: 14/01/2013. URL: http://www.ode.org.

[36] OMNeT++. Accessed: 14/01/2013. URL: http://www.omnetpp.org.

[37] OPNET modeler. Accessed: 14/01/2013. URL: http://www.opnet.com/

solutions/network_rd/modeler.html.

[38] Carlo Pinciroli, Vito Trianni, Rehan O’Grady, Giovanni Pini, Arne Brutschy,

Manuele Brambilla, Nithin Mathews, Eliseo Ferrante, Gianni Di Caro, Frederick

Ducatelle, Timothy Stirling, Alvaro Gutierrez, Luca Maria Gambardella, and

Marco Dorigo. Argos: A modular, multi-engine simulator for heterogeneous

swarm robotics. In IEEE/RSJ International Conference on Intelligent Robots

and Systems (IROS), pages 5027 –5034, sept. 2011.



http://dx.doi.org/http://dx.doi.org/10.1016/S0967-0661(98)00047-1

http://dx.doi.org/http://dx.doi.org/10.1016/S0967-0661(98)00047-1

http://doi.acm.org/10.1145/2185216.2185342

http://doi.acm.org/10.1145/2185216.2185342

http://dx.doi.org/10.1145/2185216.2185342

http://www.isi.edu/nsnam/ns

http://www.isi.edu/nsnam/ns

http://www.nsnam.org

http://www.ode.org

http://www.omnetpp.org

http://www.opnet.com/solutions/network_rd/modeler.html

http://www.opnet.com/solutions/network_rd/modeler.html

BIBLIOGRAPHY 100

[39] The player project. Accessed: 14/01/2013. URL: http://playerstage.

sourceforge.net.

[40] M. Pohjola, S. Nethi, and R. Jantti. Wireless control of mobile robot squad

with link failure. In Modeling and Optimization in Mobile, Ad Hoc, and Wireless

Networks and Workshops, 2008. WiOPT 2008. 6th International Symposium on,

pages 648–656, 2008. doi:10.1109/WIOPT.2008.4586154.

[41] R. Poovendran. Cyber-physical systems: Close encounters between two parallel

worlds [point of view]. Proceedings of the IEEE, 98(8):1363–1366, 2010. doi:

10.1109/JPROC.2010.2050377.

[42] R. Poovendran, K. Sampigethaya, S. K. S. Gupta, I. Lee, K. V. Prasad, D. Cor-

man, and J. Paunicka. Special issue on cyber - physical systems [scanning the

issue]. Proceedings of the IEEE, 100(1):6–12, 2012. doi:10.1109/JPROC.2011.

2167449.

[43] P. Prabhakaran and R. Sankar. Impact of realistic mobility models on wireless

networks performance. In IEEE International Conference on Wireless and Mobile

Computing, Networking and Communications, pages 329 –334, june 2006.

[44] E.M. Royer, P.M. Melliar-Smith, and L.E. Moser. An analysis of the optimum

node density for ad hoc mobile networks. In IEEE International Conference

on Communications, volume 3, pages 857 –861 vol.3, 2001. doi:10.1109/ICC.

2001.937360.

[45] Amit Kumar Saha and David B. Johnson. Modeling mobility for vehicu-

lar ad-hoc networks. In Proceedings of the 1st ACM international workshop

http://playerstage.sourceforge.net

http://playerstage.sourceforge.net

http://dx.doi.org/10.1109/WIOPT.2008.4586154





http://dx.doi.org/10.1109/ICC.2001.937360


BIBLIOGRAPHY 101

on Vehicular ad hoc networks, VANET ’04, pages 91–92, New York, NY,

USA, 2004. ACM. URL: http://doi.acm.org/10.1145/1023875.1023892,

doi:10.1145/1023875.1023892.

[46] Miguel Sanchez and Pietro Manzoni. Anejos: a java based simulator for ad hoc

networks. Future Generation Computer Systems, 17(5):573 – 583, 2001. I: Best

of Websim99. II: Traffic Simulation.

[47] Segway. Accessed: 15/12/2013. URL: http://www.segway.com.

[48] Gaurav S. Sukhatme, Scott Brizius, and George A. Bekey. Evaluating the mobil-

ity of a wheeled robot using dynamic modeling *. Advanced Robotics, 12(5):579–

591, 1997.

[49] Walid Taha, Paul Brauner, Robert Cartwright, Veronica Gaspes, Aaron Ames,

and Alexandre Chapoutot. A core language for executable models of cyber phys-

ical systems.

[50] Walid Taha and Roland Philippsen. Modeling basic aspects of cyber-physical

systems. CoRR, abs/1303.2792, 2013.

[51] Jing Tian, J. Hahner, C. Becker, I. Stepanov, and K. Rothermel. Graph-based

mobility model for mobile ad hoc network simulation. In 35th Annual Simulation

Symposium, pages 337 – 344, april 2002.

[52] PTV Vissim. Accessed: 14/01/2013. URL: http://vision-traffic.

ptvgroup.com/en-us/products/ptv-vissim.

[53] Junqing Wei, J.M. Snider, Junsung Kim, J.M. Dolan, R. Rajkumar, and B. Litk-

ouhi. Towards a viable autonomous driving research platform. In Intelligent

http://doi.acm.org/10.1145/1023875.1023892

http://dx.doi.org/10.1145/1023875.1023892

http://www.segway.com

http://vision-traffic.ptvgroup.com/en-us/products/ptv-vissim

http://vision-traffic.ptvgroup.com/en-us/products/ptv-vissim

BIBLIOGRAPHY 102

Vehicles Symposium (IV), 2013 IEEE, pages 763–770, 2013. doi:10.1109/IVS.

2013.6629559.

[54] E. Weingartner, H. vom Lehn, and K. Wehrle. A performance comparison of

recent network simulators. In ICC ’09. IEEE International Conference on Com-

munications, 2009., pages 1–5, 2009. doi:10.1109/ICC.2009.5198657.

http://dx.doi.org/10.1109/IVS.2013.6629559

http://dx.doi.org/10.1109/IVS.2013.6629559


Appendix A

A.1 Acumen State Serialization

The underlying client-server interaction between Acumen and NS-3 utilizes JSON to

send data back and forth as the following:

• Acumen State: Sent from Acumen to NS-3. Acumen serializes its whole state

of objects into JSON format

• State Updates: Sent from NS-3 to Acumen. NS-3 constructs a list of all

updates resulted from manipulating shared variables in order to send it to Acu-

men.

A.1.1 Acumen State

Listing A.1 shows the state of Acumen model shown in 5.1 after a executing a given

time step serialized into JSON format. As seen in the listing each object is a name/-

value pair where the name is the internal Acumen ID of the object. The object ID

also denotes a parent-child relationship. An ID such as "0.1" denotes an object with

ID "1" that is a child of object with ID 0. In this model, we have two instances of of

103

APPENDIX A. 104

the class Node, which are "0.1" and "0.2", and they are both children of the Main

object which has the ID "0". The remaining object, with the ID "0.0" is a special

internal object called the Simulator object, which keeps Acumen’s simulation time

and other information such as "timeStep" and "endTime". Note that all objects

include other variables that belong to Acumen in addition to variables users define in

their classes.

APPENDIX A. 105

Listing A.1: Acumen state in JSON.

1 {"0.0":{"stepType":{"type":"stepType", "value":"Continuous"},

"parent":{"type":"objId", "value":"Some (0)"}, "seed2":{"

type":"int", "value":2147483398} , "nextChild":{"type":"int"

, "value":0}, "endTime":{"type":"int", "value":80}, "

className":{"type":"className", "value":"Simulator"}, "

seed1":{"type":"int", "value":40014} , "timeStep":{"type":"

double", "value":0.01} , "time":{"type":"double", "value"

:0.0}} ,

23 "0.1":{"parent":{"type":"objId", "value":"Some (0)"}, "x":{"

type":"int", "value":100}, "seed2":{"type":"int", "value"

:40691} , "state":{"type":"string", "value":"Constant"}, "

nextChild":{"type":"int", "value":0}, "y":{"type":"int", "

value":100} , "t":{"type":"int", "value":0}, "t’":{"type":"

int", "value":0}, "init_v":{"type":"int", "value":16}, "x’"

:{"type":"int", "value":16}, "className":{"type":"className

", "value":"Node"}, "seed1":{"type":"int", "value":80028} ,

"init_state":{"type":"string", "value":"Constant"}, "accel"

:{"type":"int", "value":4}, "max_v":{"type":"int", "value"

:16}, "x’’":{"type":"int", "value":0}},

45 "0":{"parent":{"type":"objId", "value":"None"}, "seed2":{"type

":"int", "value":2103410263} , "nextChild":{"type":"int", "

value":3}, "className":{"type":"className", "value":"Main"

}, "simulator":{"type":"objId", "value":"Some (0.0)"}, "mode

":{"type":"string", "value":"Persist"}, "seed1":{"type":"

int", "value":4}},

67 "0.2":{"parent":{"type":"objId", "value":"Some (0)"}, "x":{"

type":"int", "value":20}, "seed2":{"type":"int", "value"

:1655838863} , "state":{"type":"string", "value":"Constant"

}, "nextChild":{"type":"int", "value":0}, "y":{"type":"int"

, "value":100}, "t":{"type":"int", "value":0}, "t’":{"type"

:"int", "value":0}, "init_v":{"type":"int", "value":4}, "x’

":{"type":"int", "value":4}, "className":{"type":"className

", "value":"Node"}, "seed1":{"type":"int", "value":120042} ,

"init_state":{"type":"string", "value":"Constant"}, "accel

":{"type":"int", "value":4}, "max_v":{"type":"int", "value"

:18}, "x’’":{"type":"int", "value":0}}

8 }

APPENDIX A. 106

A.1.2 State Updates

State updates are a list of updates that will be applied to Acumen state before

resuming its simulation. Listing A.2 shows two updates to the same model above.

Each update includes the object’s ID, the name of the variable, the type, and the

new value.

Listing A.2: State updates in JSON.

1 {

2 "0":{"id":"0.2","name":"state","value":{"type":"string","

value":"Accelerating"}},

3 "1":{"id":"0.2","name":"x","value":{"type":"double","value"

:5.010}}

4 }

APPENDIX A. 107

A.2 AcumenNS3 Classes

+Iterator : StateUpdate-m_list : StateUpdate+Begin() : Iterator+End() : Iterator+Add(update : StateUpdate) : void+AppendSet(anotherSet : StateUpdateSet *) : void+IsEmpty() : bool+Clear() : void+Find(id : string &) : StateUpdate *+ToJson() : string

StateUpdateSet

-m_valueType : UpdateValueType-m_id : string-m_name : string-m_stringValue : string-m_intValue : int-m_doubleValue : double+StateUpdate()+StateUpdate(id : string &, name : string &)+GetType() : UpdateValueType+GetObjectId() : string+GetAttributeName() : string+GetDoubleValue() : double+GetStringValue() : string+GetIntegerValue() : int+Create(id : string &, name : string &, value : int) : StateUpdate+Create(id : string &, name : string &, value : double) : StateUpdate+Create(id : string &, name : string &, value : string &) : StateUpdate

StateUpdate

-m_json : string-m_jsonReader : Reader-m_rootValue : Value+CreateFromJson(json : string) : AcumenCStore *#AcumenCStore(json : string)+GetJson() : string+GetIntegerValue(cid : string &, variable : string &) : int+GetDoubleValue(cid : string &, variable : string &) : double+GetStringValue(cid : string &, variable : string &) : string+GetTime() : double+GetStepType() : StepType+GetObjIdsFromClassName(className : string &) : ObjectIdList+GetObjectId(className : string &, index : uint32_t = 0) : string+GetObjectCount(className : string &) : uint32_t+GetObjectCount() : uint32_t

AcumenCStore

-m_nodes : NodeContainer-m_nodeIdMap : map<uint32_t, string>-m_objectIdsKnown : bool-m_controller : MobilityController*-m_objectIds : ObjectIdList-m_config : SimulationConfig*+MobilityController(config : SimulationConfig *)+MobilityController()+InstallMobility(nodes : NodeContainer) : void+GetNodeId(nodeId : uint32_t) : string+GetCurrentController() : MobilityController *-HandleMobility() : void-PopulateNodeIdMap() : void

MobilityController

-m_nodeCount : uint32_t-m_simulationEnd : double-m_className : string-m_portNumber : uint32_t-m_timeStep : double-m_mobility : bool-m_rootValue : Value+SimulationConfig(nodeCount : uint32_t, simulationTime : d...+CreateFromConfigFile(file : string &) : SimulationConfig *+GetNodeCount() : uint32_t+GetSimulationTimeEnd() : uint32_t+GetClassName() : string+GetPortNumber() : uint32_t+GetTimeStep() : double+GetMobility() : bool+GetJsonRootValue() : Value &

SimulationConfig

-m_objectIdsKnown : bool-m_handleMobility : bool-m_acumenClient : AcumenClient-m_currentStore : AcumenCStore*-m_config : SimulationConfig*-m_mobilityController : MobilityController*-m_currentUpdateSet : StateUpdateSet*-m_currentInstance : AcumenNs3Scheduler*+AcumenNs3Scheduler(config : SimulationConfig *, mobility : MobilityController * = NULL)+AcumenNs3Scheduler()+Init() : void+Run() : void+GetCurrentUpdateSet() : StateUpdateSet *+GetCurrentCStore() : AcumenCStore *+GetCurrentConfig() : SimulationConfig *+GetNodeId(id : uint32_t) : string+GetCurrentInstance() : AcumenNs3Scheduler *-SchedulerProc() : void

AcumenNs3Scheduler-m_socket : Socket*+AcumenClient()+Connect(server : string &, port : uint32_t) : void+Close() : void+Send(json : string &) : void+Receive() : string

AcumenClient

-m_currentUpdateSet

-m_list*

-m_config

-m_currentStore

-m_acumenClient-m_acumenClient

-m_currentStore

-m_config

-m_mobilityController

-m_currentUpdateSet

-m_config

-m_config

-m_mobilityController

*-m_list

Figure A.1: AcumenNS3 C++ class diagram - Part 1.

APPENDIX A. 108

+StringSharedVariable(name : string &, id : string &)+StringSharedVariable(name : string &, node : Ptr<Node>)+StringSharedVariable(variable : StringSharedVariable &)+=(value : string &) : StringSharedVariable &+=(value : char *) : StringSharedVariable &+Get() : string

StringSharedVariable

+DoubleSharedVariable(name : string &, id : string &)+DoubleSharedVariable(name : string &, node : Ptr<Node>)+DoubleSharedVariable(variable : DoubleSharedVariable &)+=(value : double) : DoubleSharedVariable &+Get() : double

DoubleSharedVariable+IntSharedVariable(name : string &, id : string &)+IntSharedVariable(name : string &, node : Ptr<Node>)+IntSharedVariable(variable : IntSharedVariable &)+=(value : int) : IntSharedVariable &+Get() : int

IntSharedVariable

#m_sharedVariable : SharedVariableImpl*+SharedVariable(type : VariableType, name : string &, id : ...+SharedVariable(type : VariableType, name : string &, nod...+SharedVariable()+HasChanged() : bool

SharedVariable

-m_sharedVariables : SharedVariableImpl*+Add(sharedVar : SharedVariableImpl *) : void+Remove(sharedVar : SharedVariableImpl *) : void+CollectStateUpdates() : StateUpdateSet *+UpdateVariables(store : AcumenCStore &) : void

SharedVariablesController-m_stringValue : string-m_type : VariableType-m_name : string-m_acumenId : string-m_hasChanged : bool-m_isInitialized : bool-m_value : union+SharedVariableImpl(type : VariableType, name : string &, id : string &)+SharedVariableImpl(type : VariableType, name : string &, node : Ptr<Node>)+Set(value : int) : void+Set(value : double) : void+Set(value : bool) : void+Set(value : string &) : void+GetIntegerValue() : int+GetDoubleValue() : double+GetBooleanValue() : bool+GetStringValue() : string+HasChanged() : bool+GetStateUpdate() : StateUpdate-GetAcumenObjectIdByName(name : string) : void-GetAcumenObjectIdByNodeId(node : Ptr<Node>) : void-ReadValueFromStore(store : AcumenCStore &) : void-CheckType(type : VariableType) : void-CheckIfInitialized() : void

SharedVariableImpl

-m_sharedVariables

#m_sharedVariable

**

-m_sharedVariables

#m_sharedVariable

Figure A.2: AcumenNS3 C++ class diagram - Part 2.

co-simulation environment for modeling networked cyber-physical

Documents