Co-simulation Environment for Modeling Networked Cyber-Physical ...
Transcript of 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
CHAPTER 1. INTRODUCTION 3
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
CHAPTER 1. INTRODUCTION 4
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.
CHAPTER 1. INTRODUCTION 5
• 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
CHAPTER 2. BACKGROUND 8
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
CHAPTER 2. BACKGROUND 9
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].
CHAPTER 2. BACKGROUND 10
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
CHAPTER 2. BACKGROUND 11
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
CHAPTER 2. BACKGROUND 12
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
CHAPTER 2. BACKGROUND 13
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
CHAPTER 2. BACKGROUND 14
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.
CHAPTER 2. BACKGROUND 15
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
CHAPTER 2. BACKGROUND 16
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.
CHAPTER 2. BACKGROUND 17
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].
CHAPTER 2. BACKGROUND 18
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
CHAPTER 2. BACKGROUND 19
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.
CHAPTER 2. BACKGROUND 20
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,
CHAPTER 2. BACKGROUND 21
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
CHAPTER 2. BACKGROUND 22
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.
CHAPTER 2. BACKGROUND 23
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
CHAPTER 2. BACKGROUND 24
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.
CHAPTER 2. BACKGROUND 25
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
CHAPTER 2. BACKGROUND 26
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
CHAPTER 2. BACKGROUND 27
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
CHAPTER 2. BACKGROUND 28
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
CHAPTER 2. BACKGROUND 29
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
CHAPTER 2. BACKGROUND 30
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.
CHAPTER 2. BACKGROUND 31
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
CHAPTER 2. BACKGROUND 32
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
CHAPTER 2. BACKGROUND 33
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.
CHAPTER 2. BACKGROUND 34
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
CHAPTER 2. BACKGROUND 35
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.
CHAPTER 2. BACKGROUND 36
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
CHAPTER 2. BACKGROUND 37
(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.
CHAPTER 2. BACKGROUND 38
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 ();
CHAPTER 2. BACKGROUND 39
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
CHAPTER 2. BACKGROUND 40
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 43
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 44
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 45
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,
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 46
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.
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 47
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 48
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 49
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 50
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 51
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.
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 52
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 53
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
CHAPTER 3. THE ACUMENNS3 CO-SIMULATION ENVIRONMENT 54
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 57
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.
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 58
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 59
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 60
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.
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 61
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 62
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 63
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 64
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.
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 65
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 66
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
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 67
with three parameters we can write: ["SomeClass", 10, 0, 20].
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 68
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));
CHAPTER 4. ACUMENNS3 IMPLEMENTATION 69
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.
CHAPTER 5. EVALUATION 72
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.
CHAPTER 5. EVALUATION 73
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.
CHAPTER 5. EVALUATION 74
0
20
40
60
80
100
120
140
160
180
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.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)
Leader speed (m/s)Follower speed (m/s)
Distance between nodes (m)
Figure 5.3: Simulation results for lead-follow using standalone NS-3 with 1 s sampling.
CHAPTER 5. EVALUATION 75
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.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.
CHAPTER 5. EVALUATION 76
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,
CHAPTER 5. EVALUATION 77
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)
Leader speed (m/s)Follower speed (m/s)
Distance between nodes (m)
Figure 5.6: Simulation results for lead-follow with variable terrain using AcumenNS3.
CHAPTER 5. EVALUATION 78
-20
0
20
40
60
80
100
120
140
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.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.
CHAPTER 5. EVALUATION 79
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
CHAPTER 5. EVALUATION 80
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
CHAPTER 5. EVALUATION 81
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
CHAPTER 5. EVALUATION 82
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.
CHAPTER 5. EVALUATION 83
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
CHAPTER 5. EVALUATION 84
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).
CHAPTER 5. EVALUATION 85
-20
-10
0
10
20
30
40
0 2 4 6 8 10 12 14
Time
inverted-pendulum
thetatheta’
xx’F
Figure 5.10: Simulation results of the inverted pendulum with 5 ms delay (point-to-point controller).
-40
-30
-20
-10
0
10
20
30
40
0 2 4 6 8 10 12 14
Time
inverted-pendulum
thetatheta’
xx’F
Figure 5.11: Simulation results of the inverted pendulum with 10 ms delay (point-to-point controller).
CHAPTER 5. EVALUATION 86
-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
CHAPTER 5. EVALUATION 87
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.
CHAPTER 5. EVALUATION 88
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
CHAPTER 5. EVALUATION 89
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
CHAPTER 6. CONCLUSION AND FUTURE WORK 92
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,
CHAPTER 6. CONCLUSION AND FUTURE WORK 93
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
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.
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.
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.
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
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.
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
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
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.
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.