A Reconfigurable Simulator For Coupled Conveyors

A RECONFIGURABLE SIMULATOR FOR COUPLED CONVEYORS
A Thesis
Presented to
The Graduate Faculty of The University of Akron
In Partial Fulfillment
of the Requirements for the Degree
Master of Science
Nunzio Hayslip
December, 2006
A RECONFIGURABLE SIMULATOR FOR COUPLED CONVEYORS

Nunzio Hayslip
Thesis
Approved:
Accepted:
Advisor
Dr. Shivakumar Sastry
Department Chair
Dr. Alex De Abreu Garcia
Committee Member
Dr. Nathan Ida
Dean of the College

Dr. George K. Haritos
Committee Member
Dr. James E. Grover
Dean of the Graduate School

Dr. George R. Newkome
Date
ii
ABSTRACT
Emerging trends in tiny embedded microcontrollers and transceivers provide
the impetus for networked embedded automation. To facilitate these investigations,
this thesis proposes a compositional approach, called Coupled Conveyors, to realize
reconfigurable conveyor systems. A discrete-event simulator for Coupled Conveyors
is presented.
Coupled Conveyors is based on three building blocks that are called Segment,
Turnaround, and Crossover. Each block is regulated by a unique microcontroller
that interacts with other microcontrollers, over wireless links, to coordinate operations. Reconfigurable conveyor systems are achieved by embedding the building
blocks in a two-dimensional grid. Using the OMNeT++ discrete-event simulation
framework, software modules were developed to model and represent the behavior of Segment, Turnaround, and Crossover. These modules were used to compose conveyor systems using the Network Description language in OMNeT++. The
conveyor system achieved is reconfigurable because the number of modules in the
conveyor system, the speed at which entities move in the system, the number of
entities, injection rates, length and type of entities are all parameters that can be
changed without requiring any software changes in the simulator. The approach
and the simulator were validated by composing conveyor systems for applications
such as Inspection and Package Sorting.
In the future, the simulator can be extended to improve the fidelity of the
dynamics of the electromechanical systems and investigate the computational and
communication foundations of networked embedded automation.
iii
ACKNOWLEDGEMENTS
I would like to express much gratitude to my advisor, Dr. Shiva Sastry. His
constant enthusiasm, support and direction were invaluable for my research and
have taught me many lessons about life.
I am grateful to Dr. Grover and Dr. Ida for agreeing to read this thesis and
for letting me borrow all sorts of debuggers, in-circuit emulators and oscilloscopes
at a moments notice.
Thanks are due to my colleagues, both past and present. To Jack Chu for his
assistance in the lab and Ruan for helping with a redesign of the simulator. Thanks
to Minlan and Kranthi for their advice and assistance with this work.
I would like to thank the ECE department for supporting me as a TA for the
Circuits I and II Labs. On that note, Id like to thank Professor Kult for making the
afore mentioned labs an enjoyable teaching experience.
Also, I would like to acknowledge Ohio ICE for financial support and for
bringing industry focused research opportunities to students.
iv
TABLE OF CONTENTS
Page
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
CHAPTER
I.
II.
III.
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Research Approach . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Overview of Thesis . . . . . . . . . . . . . . . . . . . . . . . . .
BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Discrete Event Simulation . . . . . . . . . . . . . . . . . . . . . .
2.2 Network Simulators . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Commercial Simulators . . . . . . . . . . . . . . . . . . .
11
2.3 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
COUPLED CONVEYORS . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1 Building Blocks of Coupled Conveyors . . . . . . . . . . . . . . .
15
3.1.1 Segment . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1.2 Turnaround . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.3 Crossover . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2 Composing Systems From Blocks . . . . . . . . . . . . . . . . . .
18
3.2.1 Embedding CCS in a Grid . . . . . . . . . . . . . . . . . .
19
3.3 Behavior of NEA Nodes . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.1 Specification for Segment . . . . . . . . . . . . . . . . . .
22
3.3.2 Specification for Turnaround . . . . . . . . . . . . . . . .
23
IV.
V.
3.3.3 Specification for Crossover . . . . . . . . . . . . . . . . .
23
3.4 Benefits of Coupled Conveyors . . . . . . . . . . . . . . . . . . .
24
SIMULATOR DESIGN AND IMPLEMENTATION . . . . . . . . . . . . . .
29
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2 Entity Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3 Entity Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4 Building Blocks for Coupled Conveyors . . . . . . . . . . . . . .
32
4.4.1 Metal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.4.2 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.5 Medium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.6 Monitoring Station . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.7 Building an Application . . . . . . . . . . . . . . . . . . . . . . .
38
APPLICATIONS AND RESULTS . . . . . . . . . . . . . . . . . . . . . . . .
42
5.1 Basic Simulation Setup . . . . . . . . . . . . . . . . . . . . . . .
42
5.2 Behavior of Building Blocks . . . . . . . . . . . . . . . . . . . . .
43
5.2.1 Baseline Experiment
VI.
. . . . . . . . . . . . . . . . . . . .
43
5.2.2 Experiment 1 - Segment Behavior . . . . . . . . . . . . .
46
5.2.3 Experiment 2 - Turnaround Behavior . . . . . . . . . . .
49
5.2.4 Experiment 3 - Crossover Behavior
. . . . . . . . . . . .
52
5.3 Inspection Station . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.3.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . .
57
5.3.2 Simulation Results
. . . . . . . . . . . . . . . . . . . . .
57
5.3.3 Experiment 4 - Communication . . . . . . . . . . . . . .
59
5.3.4 Experiment 5 - Fault Tolerance . . . . . . . . . . . . . . .
61
5.4 Package Sorting System . . . . . . . . . . . . . . . . . . . . . . .
61
5.4.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . .
62
. . . . . . . . . . . . . . . . . . . . .
63
5.4.3 Experiment 6 - Topology Changes . . . . . . . . . . . . .
64
5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
vi
BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
70
LIST OF TABLES
Table
Page
3.1 Notation for Specifications . . . . . . . . . . . . . . . . . . . . . . . .
22
5.1 Parameters Values . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2 Baseline Experiment Parameters . . . . . . . . . . . . . . . . . . . . .
44
5.3 Parameters for Validating Segment . . . . . . . . . . . . . . . . . . .
47
5.4 Validating the Segment Simulation Results . . . . . . . . . . . . . .
48
5.5 Effects of Changing Speed and Entity Length . . . . . . . . . . . . . .
48
5.6 Parameters for Validating the Turnaround . . . . . . . . . . . . . . .
50
5.7 Overall Simulation Results . . . . . . . . . . . . . . . . . . . . . . . .
50
5.8 Average End-to-end Travel Time Per Sink . . . . . . . . . . . . . . . .
50
5.9 Turnaround with Varying Deflect Ranges . . . . . . . . . . . . . . . .
51
5.10 Parameters for Validating the Crossover . . . . . . . . . . . . . . . .
53
5.11 Overall Simulation Results . . . . . . . . . . . . . . . . . . . . . . . .
54
5.12 Validating the Crossover - Entity Latency . . . . . . . . . . . . . . . .
56
5.13 Inspection Station Parameters . . . . . . . . . . . . . . . . . . . . . .
58
5.14 Inspection Station Simulation Results . . . . . . . . . . . . . . . . . .
58
5.15 Inspection Station Experiment 4 Results . . . . . . . . . . . . . . . .
60
5.16 Inspection Station Experiment 5 Results . . . . . . . . . . . . . . . .
61
5.17 Package Sorting Simulation Parameters . . . . . . . . . . . . . . . . .
63
5.18 Package Sorter Simulation Results . . . . . . . . . . . . . . . . . . . .
65
5.19 Reconfigured Package Sorter Results . . . . . . . . . . . . . . . . . .
65
viii
LIST OF FIGURES
Figure
Page
1.1 Traditional Automation System . . . . . . . . . . . . . . . . . . . . .
1.2 Emergence of Networked Embedded Systems . . . . . . . . . . . . .
1.3 Wireless Communicaiton in Automation . . . . . . . . . . . . . . . .
3.1 Coupled Conveyors Building Blocks . . . . . . . . . . . . . . . . . . .
15
3.2 An Example Conveyor System . . . . . . . . . . . . . . . . . . . . . .
20
3.3 Specification for Segment . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4 Specification for Turnaround . . . . . . . . . . . . . . . . . . . . . . .
26
3.5 Specification for Turnaround - Continued . . . . . . . . . . . . . . . .
27
3.6 Specification for Crossover . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1 Modules in a Segment . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2 Internals of Metal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3 Simple Conveyor System . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.1 Simple Conveyor System - End-to-end entity travel times.
. . . . . .
45
5.2 Simple Conveyor System - Entity Values. . . . . . . . . . . . . . . . .
46
5.3 Simple Conveyor System - Packet Transmission Times. . . . . . . . .
47
5.4 Entity Arriving at Sinks . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.5 End-to-end Entity Travel Times . . . . . . . . . . . . . . . . . . . . .
52
5.6 Effects of Mutual Exclusion . . . . . . . . . . . . . . . . . . . . . . .
53
5.7 An Inspection System . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.8 Inspection Station Screenshot . . . . . . . . . . . . . . . . . . . . . .
59
5.9 A Package Sorter . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
ix
5.10 Package Sorting Simulation Screenshot . . . . . . . . . . . . . . . . .
64
5.11 Package Sorter Entity values per sink. . . . . . . . . . . . . . . . . .
66
5.12 Package Sorter Mean end-to-end entity travel time. . . . . . . . . .
67
CHAPTER I
INTRODUCTION
Recent trends in device technologies offer a variety of resource-constrained

microcontrollers and low-power radio transceivers that are useful for a broad spectrum of engineering applications. Automation systems are an important class of
such engineering applications. By integrating new technologies into existing and
future automation systems, it is possible to achieve finer grain control, reconfigurable topologies, improved diagnostics, and reduced system lifecycle costs.
A traditional automation system is shown in Figure 1.1 [1]. A controller is
hard-wired to the conveyor modules and human interface devices. The controllers
are interconnected via one or more levels of supervisory controllers.
The integration of new technologies into automation systems requires one to
alter the existing engineering methods. For example, in the current method, the
system is highly engineered i.e., the system is carefully designed, implemented,
verified, commissioned, and operated. However, because of the inherently nondeterministic operating environment, there are about 15 to 35 disruptions that are
caused in an average eight hour shift. Plant floor technicians compensate for such
changes using ad-hoc methods that are sometimes guided by thumbrules. When
the changes implemented by such ad-hoc methods are not updated in the design
documents, it is easy to see that the system that is operating is significantly different
from the system that was designed. This discrepancy is one of the principal causes
for the high operating and maintenance costs associated with automation systems.
In contrast, emerging technologies make it feasible to design automation systems with reconfigurable topologies. Networked embedded systems may be appro-
Supervisory Controller
Automation System
Input
Output
Control Behavior
Specification
HCI
Logic Processing
Controller1
Controller3
Programming
Tool 1
Programming
Tool 3
Sensors &
Actuators 1
PB Panel 1
Controller2
Programming
Tool 2
Zone 1
Sensors &
Actuators 3
PB Panel 3
Zone 3
PB Panel 2
t
Sensors &
Actuators 2
Zone 2
Figure 1.1: Traditional Automation System

priate for this task. Figure 1.2 depicts the emergence of networked embedded systems as a natural outcome of technology development. A view of the impact of
wireless communication on future automation systems is shown in Figure 1.3.
To explore methods to integrate new technologies with automation systems,
a simple class of automation systems, namely conveyor systems, was selected. A
compositional approach, called Coupled Conveyors, was developed to achieve reconfigurable systems using three building blocks that are called Segment, Turnaround,
and Crossover. A local microcontroller, which was integrated with a low-power radio transceiver, is associated with each building block. These microcontrollers comprised the underlying networked embedded system that regulated the operation of
the conveyor system. It was then necessary to develop methods and tools to analyze
the validity and performance of such conveyor systems. This thesis presents a discrete
event simulator for validating and studying the performance of Coupled Conveyors.
Inherent Distribution
Performance
Incremental Growth
Economics
Distributed
Computing
Safety
Predictability
Reliability
Maintainability
Automation
Systems
Networked
Embedded
Systems
Mobile
Computing
Mobile Devices
Wireless
Energy Awareness
Location Awareness
Sensor Networks
Resource Limited
Energy Conserving
Figure 1.2: Emergence of Networked Embedded Systems

1.1
Motivation
The overriding question that motivated this investigation is whether it was
feasible to develop a reconfigurable discrete event simulator that is useful to simulate and study the performance of a variety of conveyor systems. In addition, it
was necessary to validate the compositional approach advocated for Coupled Conveyors by ensuring that it was scalable and not restricted to a particular instance of
conveyor systems.
The Coupled Conveyors approach was originally developed as a part of this
research [2]. Thus, it was clear that there was no existing simulator for Coupled
Conveyors. The state of the art in discrete event simulators is discussed in Chapter
II. These simulators largely focus on the networking issues. To support the simulation of a system such as a conveyor system, or a traffic system, it is necessary
to simulate the dynamics of the physical system independently and create a data
set that can be used to exercise the sensor network simulator. Such an approach
cannot capture the dynamic interaction between the physical system and the networked embedded system that regulates its operation.
3
Automation System
Input
Output
Retargetable
Programming
Devices
HMI
Logic Processing
Monitoring Specific
Behavior
Module
Wired
Retargetable
Push Button Panel 1
Communication Media
(Wireless with wired
segments)
Wireless
Retargetable
Push Button Panel 2
Figure 1.3: Wireless Communicaiton in Automation

1.2
Research Approach
Discrete event simulation is a robust technology that has evolved over the
last thirty years. A well-known framework for discrete event simulation called OMNeT++ was selected. Using object-oriented design principles, the building blocks,
i.e., Segment, Turnaround, and Crossover, were modeled as software modules in
the C++ programming language. The Network Description language supported by
OMNeT++ was used to specify Coupled Conveyor topologies for conveyor systems
that are useful in a variety of material movement applications. The performance of
the conveyor systems was characterized both at the level of entities moving over the
conveyor system and at the level of electronic events that occurred in the networked
embedded system.
1.3
Contributions
The contributions of this thesis are:
1. A compositional approach for conveyor systems called Coupled Conveyors.

2. A reconfigurable, discrete event, simulator for Coupled Conveyors.
3. Analysis of the performance of the discrete event simulator.
A simulator for Coupled Conveyors is an invaluable design tool. This simulator can be used to evaluate end-to-end entity travel times, message latencies, effects
of failures on the system and effects of topology. The simulator will also allow one
to study the effects of changes in entity rates, motor speed, etc. on the networked
embedded system. Without such a simulator, the design and deployment of Coupled
Conveyor applications is likely to be difficult, if not impossible.
1.4
Overview of Thesis
Chapter II describes discrete event simulation and provides an introduction
to the OMNeT++ framework for discrete event simulation. Existing simulation

frameworks and sensor network simulators are also discussed. In Chapter III, Coupled Conveyors is defined in detail with an example to illustrate how Segment,
Turnaround, and Crossover are used to compose conveyor systems. The objectoriented design of the simulator is presented in Chapter IV. The Network Description language, which is useful to compose conveyor systems from the building
blocks, is discussed. In Chapter V, results from several experiments are presented
to demonstrate that the behavior of the software modules for each building block is
correctly achieved. Two examples are presented to demonstrate how these building
blocks are useful to realize practical conveyor system applications. These example
systems are simulated and the results are interpreted to demonstrate the integrity
of the new simulator. Chapter VI presents the conclusions from this investigation
and identifies future avenues for continued research on the simulator.
CHAPTER II
BACKGROUND
This chapter briefly describes discrete event simulation and surveys the literature of available simulators. A framework called OMNeT++ was selected as the
simulation platform for this investigation. This framework and its capabilities are
also described.
2.1
Discrete Event Simulation

Many types of systems can be adequately modeled as a time-ordered se-
quence of events. Fundamental assumptions in this approach are that (a) events
occur instantaneously and without duration, and (b) nothing significant occurs between two successive events. Such a system of events is referred to as a Discrete
Event System [3].
Simulation is the art of mimicking behavior of systems in a computing environment. There are two approaches to simulation - the first based on time-driven
execution and the second based on event-driven execution [4]. Because of the
tremendous success in using discrete event framework for representing a variety
of systems such as biological systems, manufacturing systems, telecommunication
systems, and social systems, the event-driven approach has become the dominant
approach for simulation.
The critical activity that is necessary for discrete event simulation is to maintain a queue of events that must be processed in the time-order they were generated. This activity can be accomplished in software by designing proprietary data
structures or by using a framework for simulation.
6
Before discussing the simulation method in this thesis, the following sections
outline current simulators and their limitations.
2.2
Network Simulators
Many simulators have been reported in the literature. Traditional network
protocol simulators have been extended to support simulation of sensor networks

by incorporating models for wireless channels, new Media Access Control (MAC)
protocols, and energy models for the nodes. Among such simulators, Network Simulator 2 (NS-2) is dominant and has been used in academic research. Such a simulator was considered for simulating the network embedded systems that regulate
the operations of Coupled Conveyors.
NS-2 is a discrete event-driven simulator written in C++ with an OTcl configuration interface [5]. OTcl is an Object-Oriented version of the scripting language
called Tcl. Simulations are defined by manually declaring nodes and connections
between them in an OTcl script. The behavior of individual nodes is also described
in OTcl by deriving a new class from either the base class, TclObject, or another
class derived from the base class. NS-2 provides an extensive library of classes useful for many types of protocols (routing, MAC, etc.), mobile networking, satellite
networking, radio propagation and energy models. NS-2 comes with The Network
Animator, referred to as NAM, for animating network simulation trace files.
The weakest aspect of NS-2, despite its continued popularity, is that the radio
propagation models are unrealistic. It is now well known that the results based on
NS-2 simulations are not consistent with experiments conducted on sensor network
testbeds [6].
TinyOS is the dominant platform for developing sensor network applications [7]. TOSSIM is a simulator that is developed for the TinyOS platform [8].
Applications that can be simulated under TOSSIM must be developed in the eventtriggered paradigm supported under TinyOS. While this paradigm is useful for lowdemand applications such as Habitat Monitoring, it is not clear that it is suited for
applications such as Coupled Conveyors. In addition to restriction of the develop-
ment environment, it is known that the models for radio simulation and the energy
used in TOSSIM do not reflect the observations on testbeds and experiments [6, 9].
PowerTOSSIM [10] is an extension to the TinyOS simulator, TOSSIM, focused on modeling energy usage. It calculates power consumption at the node
level by interfacing with TinyOS components and taking into account the usage of
hardware such as LEDs and the radio. A code-transformation technique removes
the need for instruction-level simulation by estimating the number of CPU cycles
used. To evaluate the accuracy of the simulator, the authors ran various TinyOS
example applications for one minute and measured the actual power usage. This
data was compared with the power consumption predicted by the simulator and an
average error of 4.7% was reported.
ATEMU is a fine grained sensor network simulator [11] which relies on a
hybrid approach where the nodes are emulated on an instruction by instruction
basis and the wireless communication is simulated in a realistic manner. Heterogeneous networks, those with multiple hardware platforms, are also supported,
though this support is limited to AVR processor based systems. A graphical debugger, called XATDB, is provided and can step through instructions on each node in
either C or at assembly level. To perform simulation, ATEMU uses the binary file
that would normally be used to program a node along with an XML configuration
file to set up the network. It is emphasized by the authors that the high-level of
detail sought by the simulator requires long run times to attain. Results show that
it takes 50, 125, and 250 real seconds to simulate 1 second in a network with 25,
50, and 80 nodes, respectively.
Avrora [12] is a cycle-accurate sensor network simulator that can scale up
to 10,000 nodes and run up to 25 nodes in real-time. An event queue is used
to handle instruction-level simulation. Such simulations are used when there is
no access to the actual hardware or when prototyping. Some existing simulators
instead use models of the nodes rather than actual software: this is sufficient for
determining network characteristics and power usage on the order of 10,000 nodes.
Each node is executed as a separate thread and this approach can impose a limit on
the simulation. Avrora does not model clock drift that is inherent in the nodes.
Simulators, such as TOSSIM and ATEMU, that run the application source
code unchanged (or nearly unchanged) have more accuracy. TOSSIM loses timing/interrupt information, while ATEMU retains it but runs 30 times slower. Avrora
maintains per node timing information but achieves performance gains over ATEMU
by only synchronizing when necessary, as opposed to ATEMU, which synchronizes the timing amongst nodes every cycle. The synchronization is necessary to
ensure proper ordering of radio communications and the global time scale. The
event-queue structure Avrora uses is ideal for sensor nodes whose programs have
them sleep often to conserve power. Their results show Avrova as 50% slower than
TOSSIM and 20 times faster than ATEMU.
SensorSim [13] is a framework whose goal is to model military tactical
environment scenarios, such as using a sensor network to monitor enemy tank
movements. It uses a sensor function model to abstract the details of sensor node
software, and as a parallel layer it uses a power model to simulate hardware. SensorSims network protocol stack simulates a WaveLAN wireless card with an 802.11
MAC Layer. These models are implemented as objects in the NS-2 simulator.
Hybrid simulation is supported, where network traffic is sent and received
from real nodes. A middleware (SensorWare) platform is also provided and runs
on the Tcl scripting language. By running SensorWare on nodes in SensorSim,
the power efficiency of SensorWare applications can be assessed. SensorSim is no
longer supported or available.
Global Mobile system Simulator (GloMoSim) [14] is a library built for the
sequential and parallel simulation of wireless networks. The provided API simulates a number of wireless communication protocols. Different types of protocols
operate on different layers. Simulations can then be reconfigured with different
protocols at one layer while keeping the same protocols on other layers. GloMoSim
is written in PARSEC, a C-based language for parallel simulation [15]. To allow for
parallel simulation, a network is split into partitions, each of which are then mapped
to a processor. Favorable Speedup from parallelization is shown by spreading sim-
ulations across, up to, 16 processors.

J-Sim [16] was built on top of SensorSim but uses its own component architecture and internetworking framework. It does share a number of SensorSims
features, including the power consumption modeling and support for hybrid simulation. Also it maintains GUI and Scripting interfaces via the Tcl extensions for Java.
This allows classes to be glued together in script files to configure simulations.
A sensor protocol stack is used over the sensor channel while a wireless protocol
stack is for communication between nodes. J-Sim supports two built-in routing
protocols: Ad-hoc On-demand Distance Vector (AODV) routing and Greedy Perimeter Stateless Routing (GSPR). Three models for wireless propagation are included
for various types of terrain. Other examples include using J-Sim for localization,
directed diffusion and geographic routing. Benchmarking shows J-Sims memory
usage is scalable but they perform 42% slower than NS-2: the overhead of Java is
claimed to be the cause of this.
JDEVS [17] is a Java implementation of the Discrete EVent System (DEVS)
specification based modeling framework. Driven by the complexity of large environmental systems that escape definition through a single metaphor, JDEVS allows
the use of and interaction between multiple modeling paradigms. The framework is
based on the multifaceted modeling methodology where modular building blocks
are wired together to form hierarchical systems. JDEVS offers extensions to the
DEVS formalism to allow for supervised learning models (Feedback-DEVS) and for
models in vector space (Vector-DEVS). JDEVS has a GUI with 2D and 3D visualization panels along with interfaces for XML and GIS Data. This toolkit is heavily
geared toward, but not limited to, environmental science modeling.
SimJava is a discrete-event process-based simulation API [18] with the unique
ability to run animated simulations as Java applets on a website. Simulations are
constructed with sets of entities connected to ports by which event objects pass
through. The behavior of an entity is specified by subclassing the base class and
then providing the necessary code. SimJavas statistics collection capabilities are
meager at best, but some extensions upon it have sought to improve this.
10
VisualSense [19] is a modeling and simulation package for wireless sensor

networks, built on top of the Ptolemy II [20] framework. It utilizes a componentbased construction of network models and an actor oriented definition of nodes,
channels, physical media and subsystems. Custom components are created by subclassing base classes in Java and providing the appropriate behavior. A GUI is used
to visualize simulations, inspect composite actors and edit parameters for actors or
channels. The GUI also has powerful model construction functionality, allowing the
user to drag in existing actors from the library, add ports, and wire them together
with utility actors (such as clocks, expression evaluators and switches) to describe
new behaviors without having to write new code.
2.2.1 Commercial Simulators
There are several commercial software packages that are used for discrete
event simulation. For example ARENA is used extensively for simulating manufacturing processes and systems [21]. OPNET is used to model communication
networks and systems [22].
2.3
OMNeT++
OMNeT++ has been use for a wide variety of purposes, from IPv6 and MAC
Protocols to Wireless Sensor Networks and Wireless Channel Simulators [23]. OMNet++ has been used successfully for simulating wireless networks [24], mobile
networks [25], and MAC protocols [26]. The simulator in this thesis is designed
and implemented within the OMNeT++ framework to take advantage of its features.
To simulate a system in OMNet++, it is necessary to design and implement
modules. For example modules may represent the network, protocols, specialized
hardware, radio transceivers, microcontrollers, etc. Each module has a fixed number of input or output ports that are also referred to as gates. Instances of such
modules are composed together to form large systems by wiring the outputs of certain modules to the inputs of other modules.
11
OMNet++ supports simple and compound modules. For each simple module, it is necessary to precisely describe the behavior of the module using a simple
extension of the C++ programming language. Compound modules are defined by
composing two or more simple modules or previously defined compound modules.
The behavior of the compound module is derived from the behavior of its simple
modules and the interactions between the simple modules. No additional behaviors
can be specified for compound modules.
OMNet++ is based on a message-passing paradigm. The communication
between modules is specified using gates. The number and type of each gate used
in a module is defined. The output gates of one module are connected to input gates
of other modules using connections. The connection can model the characteristics
of a channel using parameters such as bandwidth, bit error rates and propagation
delay [27].
A simulation entity called a message is passed between the instances of two
modules that communicate. Custom messages can be defined by subclassing cMessage or by generating C++ code from the compact syntax of a message definition
file using the message subclassing compiler.
A high-level interpreted language called NED is used to define compound
modules, interfaces for simple modules and parameters and connections for or between both. While a compound module is solely defined in a NED file as a wiring
between other modules, the behavior of simple modules must be defined in C++ by
creating a class which inherits the cSimpleModule class from the library. Further
configuration and parameter values can be specified in the omnetpp.ini file, which
allows for different sets of parameter values during different Runs.
Simulations can be run in a graphical environment, called Tkenv, for visual
inspection and animation of networks of modules. Icons and colors can be specified
for different modules, and messages are shown as they are sent: moving from one
module to another. Varying levels of detail can be observed: clicking on a compound module will open a new window showing its contents and the messages sent
therein. Clicking on a simple module will provide a window showing its parameters,
12
gates and their connections. This Graphical User Interface (GUI) and OMNeT++
itself are both cross-platform, meaning that the same code can be compiled to create executables for Windows, Linux or other platforms without the overhead of a
Virtual Machine (a l`
a Java).
The OMNet++ framework was used to simulate the behavior of the building
blocks and conveyor systems based on the compositional method described in the
next chapter.
13
CHAPTER III
COUPLED CONVEYORS
Automation systems are distributed real-time systems that perform rigorous

tasks in a safe, predictable, and robust manner [1]. Applications of automation
systems include assembly lines, manufacturing plants, amusement park rides, and
safety critical infrastructures. Conveyor systems are simple, and important, subsystems of many automation systems. To simplify maintenance and reduce installation
costs, larger conveyor systems are assembled using smaller components [28].
This thesis advocates a compositional approach for future conveyor systems.
This approach, called Coupled Conveyors, is based on three building blocks. Each
building block has a fixed number of sensors and actuators as discussed in Section
3.1. The conveyor system is regulated by a networked embedded system and we
refer to this approach to automation, in which a collection of embedded microcontrollers regulate automation applications, as Networked Embedded Automation
(NEA) [2].
The sensors and actuators on every building block are connected to a resourceconstrained microcontroller. This microcontroller regulates the local operations
of the block. The behavior of each building block is precisely specified using the
UNITY [29] in Section 3.3.
The microcontrollers sense values from sensors and communicate the sensed
values to other microcontrollers, as necessary. Based on local sensed information,
and data arriving from other microcontrollers, each microcontroller determines values for the actuators the building block it regulates. The microcontroller, the sensors
and actuators connected to it, and the integrated radio transceiver is collectively re-
14
ps
pd Port D
Port A
e1
uA
uB
Port B
e2
dD
dC
Port C
Segment 2
Segment 1
(a) Segment
(b) Turnaround
(c) Crossover
Figure 3.1: Coupled Conveyors Building Blocks

ferred to as a NEA Node.
Section 3.2 shows how NEA nodes can be embedded in a grid to compose
large conveyor systems. This approach is a compositional approach because conveyor systems are obtained by simply placing the building blocks in appropriate
positions. There is no need for programming or configuring the system. By incorporating monitoring stations and operator interaction panels to support humancomputer interaction (HCI),a complete conveyor system is achieved.
3.1
Building Blocks of Coupled Conveyors

The building blocks used in Coupled conveyors are shown in Figure 3.1.
These blocks are referred to as a Segment (Figure 3.1a), Turnaround (Figure 3.1b
and Crossover (Figure 3.1c).
The building blocks use sensing and actuation components with similar behavior. Sensors are used to detect the presence or absence of an entity. A sensor is
nominally assumed to be in an inactive state. When an entity is present in the proximity of a sensor, the sensor is in an active state. An actuator is said to be energized
when it is asserted. When energized, the associated component such as a motor or
a valve is operated. Otherwise the actuator is said to be deenergized.
3.1.1 Segment
A Segment is a module of fixed length along which an entity may move in a
specified direction. Nominally, entities arrive at the upstream end and leave via the
downstream end. Two sensors, one called the upstream sensor (u) and the other
15
called downstream sensor (d)1 are attached to the segment at fixed locations. These
sensors detect the presence or absence of an entity at their respective locations. The
actuator of a segment (a) may be energized to move the belt (of the segment) in
either a clockwise or a counterclockwise direction in one of several preset speeds.
When an entity arrives, the upstream sensor (u) detects the entity. The entity
moves along the segment as long as the actuator is energized. When the entity
arrives at the downstream end of the segment, the downstream sensor (d) detects
the entity. The duration for which the sensors remain in the active state and the
duration over which an entity moves along the segment are a function of the belt
speed and length of the entity along the direction of motion.
A Segment may be composed with other Segments, Turnarounds or Crossovers.
A set S is used to represent all the segments in an instance of coupled conveyors.
Given si S, si .a denotes the actuator of the segment; si .u denotes the upstream
sensor and si .d denotes the downstream sensor.
3.1.2
Turnaround
A Turnaround is a module of fixed length over which an entity moves. A
Turnaround is used either to introduce a fork in the stream of entity flow or to

coalesce two streams into one stream. A Turnaround has four ports labeled A, B, C,
and D. Ports A and B, referred to as input ports, are nominally assumed to be at the
upstream end of a Turnaround. Ports C and D, which are called output ports, are at
the downstream end. Entities enter a Turnaround via an input port and leave via
an output port.
The upstream sensors (uA, uB) and downstream sensors (dC, dD) detect
the entry or exit of an entity. If the part deflector (pd) is energized, entities in the
Turnaround would leave via port C; otherwise, the entities leave via port D. This
decision, i.e., whether or not a given entity must leave via port C, is not made by
the Turnaround. As seen in Section 3.2, this decision is made by the NEA Node that
is attached to the Turnaround and may require the use of additional sensors such
1
One may use redundant sensors if desired instead of a single upstream and downstream sensor.
16
as a camera, weighing scale, or an RFID scanner. Once such a decision has been
made, the part deflection sensor (ps) can be used to determine the duration over
which the spring-loaded part deflector (pd) must be energized to deflect a part to
port C. Similar to a segment, there is an actuator (a) that can be energized to turn
the belt either in the clockwise direction or the counterclockwise direction in one
of several speeds.
A Turnaround can be composed with either a segment or another turnaround
at any of the ports, as long as the direction of motion of the entities is compatible.
Such a module, i.e., a Segment or another Turnaround, must be present at least at
one input port and at one output port. The set of Turnarounds in an instance of
coupled conveyors is represented as T . For ti T , ti .a refers to the actuator that
turns the belt and ti .pd refers to the actuator of the part deflector. The upstream
sensor on ports A and B are referred to as ti .uA and ti .uB and the downstream
sensors on ports C and D are ti .dC and ti .dD. The part deflection sensor is ti .ps.
3.1.3 Crossover
A Crossover is a module that is used to transfer an entity from one segment
to another. The two segments at either end of a Crossover are referred to as end
segments. There are two end sensors, e1 and e2, for every Crossover; these sensors
detect the presence of a part that is ready to be transfered. As in a Turnaround, the
decision to transfer a part from one Segment to another must be made by the NEA
Node. The Crossover is used to carry out such a decision, after it has been made.
This module features an essential difference in behavior from the other two
modules. In the case of both the Segment and the Turnaround, when a part passes
from one module to the next, the modules interacting must both be moving, and
in the same direction. In the case of the Crossover, however, this is not true. For a
part to be properly moved out of an end segment and on to the Crossover (and the
other way around), the end segment must be stopped. So when a part is identified
to be moved on to a Crossover, the Segment that the part is currently on must be
ordered to stop, along with the Segment at the other end of the Crossover.
17
Let G1 be the Segment at the location of end sensor e1 and G2 be the Segment
at e2. When an entity arrives at e1 on G1, e1 transitions to an active state; similarly
at e2. There is an actuator on every Crossover that is used to move the entity from
G1 to G2 or from G2 to G1. To emphasize the bi-directional transfers, the actuator
is referred to as a1,2 when it is moving an entity from e1 to e2 and a2,1 when it is
moving from e2 to e1.
The symbol C is used to represent the set of all Crossovers in an instance of
coupled conveyors. Given ci C, ci .a1,2 and ci .a2,1 refer to the actuator; ci .e1 and
ci .e2 refer to the end sensors of the Crossover.
3.2
Composing Systems From Blocks

Given a specific application for a conveyor system, one must identify the
number of Segments, Turnarounds and Crossovers that are required to compose a

conveyor system for the application.
Definition 1. Every instance of Coupled Conveyors is a 6-tuple
CCS = (ESource , ESink , S, T , C, H)
where
ESource is a set of Sources for entities,
ESink is a set of Sinks for entities,
S is a set of Segments,
T is a set of Turnarounds,
C is a set of Crossovers, and
H is a set of HCI devices.
Every member of ESource can inject entities into CCS at some rate. For example, the point at which bags are loaded to a baggage handling system is an entity
18
source. A member of ESink represents points at which entities leave CCS. For example, a loading dock where material is loaded on a truck is an entity sink.
HCI devices, H, are monitoring stations or operator panels. A monitoring
station is used to observe the status of every module in CCS; an operator panel is
used to interact with CCS. Typically HCI devices are used to change the mode of
CCS, perform diagnostic or fault management tasks.
3.2.1
Embedding CCS in a Grid

The basic modules of coupled conveyors can be embedded in any regular tes-
sellation of a two-dimensional plane based on hexagons or triangles. By adjusting

the resolution of the grid, hexagon or triangle, conveyor systems can be developed
to approximate the topology of a particular application. In most manufacturing and
warehousing applications, conveyor systems are designed and operated based on
the idea of a zone which is essentially a tile in a virtual grid for the facility [28].
Consider the instance of Coupled Conveyors shown in Figure 3.2. This instance represents an application of coupled conveyors for material inspection and/or
sorting. There are 18 Segments, 4 Turnarounds and one Crossover in this instance.
The module identities are shown next to each module. For example, port D of
Turnaround T4 is embedded at grid location (1,1) and port A of Turnaround T2 is
embedded at grid location (5,3). Crossover C1 is considered as being embedded
at grid location (2,3); HCI devices H1 , H2 , and H3 are embedded at grid locations
(1,0), (3,4) and (5,0), respectively. All the other modules are embedded with appropriate directions as shown in Figure 5.72 .
Entities come in to the system via S6 (at port A of T2 ) or S17 (port A of
T3 ). Entities leave the system via port D of T4 or via S1 (at port D of T1 ). Entities
coming in via S6 may be moved either along the path < T2 , S7 , S8 , S9 , S10 , T1 , S1 >
or along the path < T2 , S16 , T3 , S14 , S13 , T4 , S11 , T1 , S1 >. Entities may be deflected
for re-inspection via port C of T3 . Defective or oversized material that are likely to
2
In addition to the sensors and actuators on the modules such an application would use additional
devices such as cameras, RFID tags and scanners, weighing scales, etc. to inspect the entities that
are being moved.
19
0,5
H2
0,4
S1
S2
S3
S4
S5
S8
S7
S6
0,3
T1
T2
C1
S10
S9
0,2
Manual
Inspection
S12
S11
S16
S15
0,1
S13
T4
S18
S14
S17
T3
North
H1
0,0
H3
1,0
2,0
3,0
4,0
5,0
Figure 3.2: An Example Conveyor System
20
6,0
damage the inspection devices along the subpath < S10 , T1 > may be diverted using
C1 . Entities coming into T3 can be moved along the subpath < T3 , S14 , S15 >, or
deflected at port C of T3 for manual inspection. Manually inspected entities may be
re-inserted into the system via port B of T4 . The HCI devices are used to monitor
the status of all modules and the operator panels can be used to issue commands
such as start, stop, or force manual inspection for all entities over a duration of
time. There are several other possibilities for moving entities in coupled conveyors
that are not discussed in the examples in this paper.
3.3
Behavior of NEA Nodes

Segments, Turnarounds, Crossovers, Source, Sinks, and HCI devices in CCS
are associated with a resource constrained microcontroller i M. Each i M is

integrated with a low-power radio transceiver. The transmission range of i is such
that only the immediate neighbors of i in the grid are able to receive its signals.
Each microcontroller is responsible for:
1. Acquiring sensor values in the building block with which it is associated,
2. Determining values for the local actuators, and
3. Executing the specifications in Section 3.3.1 to regulate the operations of CCS.
The remainder of this section presents the behavior specifications for each
building block in UNITY [29]3 . This style of specifications were chosen because
of the natural manner in which the behavior of each building block fits into the
guarded command notation of UNITY. The notation used in the specifications are
shown in Table 3.1.
The execution model of UNITY is as follows: Each specification consists of a
set of guarded actions. Actions are executed in rounds. In each round, an action is
selected non-deterministically from the set of actions. The guard of this action is
evaluated; if the guard is true, then the action is said to be enabled and is executed.
If the guard is false, then the action is not enabled, and is not executed.
3
Note that these specifications only cover the automatic mode of operation.
21
Symbol
s
s
s%
s&
a
a
*a
+ a
Meaning
Sensor s is active
Sensor s is inactive
Sensor s made a transition from inactive to active
Sensor s made a transition from active to inactive
Actuator a is energized
Actuator a is de-energized
Actuator a is being energized
Actuator a is being deEnergized
Table 3.1: Notation for Specifications
3.3.1
Specification for Segment

An NEA node that regulates the operations of a Segment must execute the
specification shown in Figure 3.3.

In action S1 , when si .d detects the presence of a part, the NEA node must
send a message to the downstream building block requesting to energize the downstream actuator to facilitate transfer of a new entity. When a Segment receives a
request to energize its actuator (action S2 ), it checks its own status to see if another
entity can be accepted. Because the NEA node cannot determine whether or not
the entity would actually arrive, it energizes its actuator, si .a and starts a watchdog
timer, mW DT , with a preset time (mW DT.preset). As shown in actions S3 and
S4 , if an entity arrives on the Segment before mW DT expires, then the watchdog
timer is reset and si .a continues to remain energized. If, however, mW DT expires
before the entity arrives on the Segment, si .a is deenergized. In action S5 , when a
Segment detects a transition from an active state to an inactive state in its upstream
sensor, si .u, it assumes that a new entity has arrived on the Segment; it, therefore,
notifies its upstream module that the actuator may be deenergized. In actions S6
and S7 , whenever a Segment receives a request to deenergize its actuators, it checks
to determine whether it is already servicing additional entities. If not, the actuator
is deenergized, otherwise, the actuator continues to remain energized.
22
3.3.2 Specification for Turnaround

The specifications that must be executed by a NEA node for a Turnaround
are shown in Figure 3.4 and Figure 3.5. In comparison to a Segment, a Turnaround
has two input ports and two output ports. The behavior of the Turnaround with
respect to the upstream (uA, uB) and downstream (dC, dD) sensors is similar to
that of a Segment. Actions T1 T13 are, correspondingly, similar to the actions in
a Segment.
A Turnaround has one watch dog timer (mW DT ) to regulate the flow of
entities from either input port as shown in action T5 . The boolean variable acceptingEntity is used in actions T3 , T4 , T7 , and T9 to ensure that entities do not arrive
simultaneously on ports A and B. Action T14 shows that the entity deflector (pd)
on a Turnaround is energized only for the duration that the entity sensor (ps) is in
an active state, when an entity must be deflected. The decision to deflect an entity must be made in an application specific manner by the NEA node by setting the
Boolean variable deflectEntity appropriately. As soon as the deflector is deenergized,
it returns to its resting state because it is a spring-loaded actuator.
3.3.3 Specification for Crossover
The specification for a Crossover is shown in Figure 3.6. As discussed earlier,
once a decision to move an entity over a Crossover has been made in the NEA Node,
the Crossover waits to see a transition from the inactive state to the active state in
one of its end sensors. When such a transition is detected, the Crossover forces the
Segments at both ends to stop (actions C1 and C2 . When the Segments have stopped
(i.e., the Crossover has received acknowledgments from both end Segments that
they have stopped), the Crossover energizes its own actuators to move the entity to
the other end Segment (actions C5 and C6 ). When the part has reached the other
target end of the Crossover, and the end sensor transitions to the active state, the
Crossover allows both end Segments to resume their activity (actions C3 and C4 ).
23
3.4
Benefits of Coupled Conveyors

Coupled Conveyors offers several benefits over existing approaches to de-
signing and implementing conveyor systems. The reduction in wiring costs because
of using a wireless media for communication is obvious. Further, wireless connectivity improves safety because it eliminates the need to install and maintain wired
access points in hazardous environments. Because the blocks are self-contained and
pre-programmed, the interaction between two blocks for an application depends
only on where the block is placed in the grid. There are no other configuration,
commissioning or setup costs. This advantage allows one to create flexible topologies for systems.
For example, in the material inspection application shown in Figure 3.2, suppose in some seasons that a higher volume of materials are received. To reduce
latency, the conveyor systems can be reconfigured simply by adding more blocks
to form additional paths. When the high volume season has passed, the same blocks
can be removed to reduce power usage. There is no reprogramming or configuration involved when the topology changes in this manner because the interactions
between blocks are designed to accommodate such changes.
24
BuildingBlock Segment
var
beltFull: Boolean
numEntities: Integer
initially
beltFull (numEntities = lenm /lene )
assign
S1 : d %
OutChanneld := Req-Actuator-On
[]
S2 : InChannelu = Req-Actuator-On beltFull
*a
;
mW DT.Start
[]
S3 : mW DT.done u a

+ a
[]
S4 : mW DT.tt u %
mW DT.Stop
numEntities := numEntities + 1
[]
S5 : u &
OutChanneld := Req-Actuator-Off
[]
S6 : InChanneld = Req-Actuator-Off numEntities = 0
+ a
[]
S7 : d &
numEntities := numparts 1;
[]
S8 : numEntities = 0 a

+ a
[]
end Segment
Figure 3.3: Specification for Segment
25
BuildingBlock Turnaround
var
beltFull: Boolean
acceptingEntity: Boolean
deflectEntity: Boolean
numEntities: Integer
initially
beltFull (numEntities = lenm /lene )
assign
T1 : dC %
OutChannelC := Req-Actuator-On;
[]
T2 : dD %
OutChannelD := Req-Actuator-On;
[]
T3 : InChannelA = Req-Actuator-On beltFull acceptingEntity
*a
;
acceptingEntity := true;
mW DT.Start;
[]
T4 : InChannelB = Req-Actuator-On beltFull acceptingEntity
*a
;
acceptingEntity := true;
mW DT.Start;
[]
T5 : mW DT.done uA uB a

+ a;
mW DT.Stop;
[]
T6 : mW DT.tt uA % a

mW DT.Stop;
numEntities := numEntities + 1
[]
T7 : uA &
acceptingEntity := false;
OutChannelA := Actuator-Off;
[]
T8 : mW DT.tt uB % a

mW DT.Stop;
numEntities := numEntities + 1;
[]
Figure 3.4: Specification for Turnaround
26
T9 :
uB &
acceptingEntity := false;
OutChannelB := Actuator-Off;
[]
T10 : InChannelC = Req-Actuator-Off numEntities = 0
+ a;
[]
T11 : InChannelD = Req-Actuator-Off numEntities = 0
+ a;
[]
T12 : dC &
numEntities := numEntities 1;
[]
T13 : dD &
numEntities := numEntities 1;
[]
T14 : def lectEntity ps%
*f
pd;
[]
T15 : numEntities = 0 a

+ a;
[]
end Turnaround
Figure 3.5: Specification for Turnaround - Continued
27
BuildingBlock Crossover c
assign
C1 : e1% a 12 a 21
OutChannels1 := ForceStop;
OutChannels2 := ForceStop
[]
C2 : e2% a21 a 12
OutChannels1 := ForceStop;
OutChannels2 := ForceStop
[]
C3 : e2 af
12
+ a12 ;
OutChannels1 := ReleaseStop;
OutChannels2 := ReleaseStop
[]
C4 : e1 af
21
+ a21 ;
OutChannels1 := ReleaseStop;
OutChannels2 := ReleaseStop
[]
C5 : InChannels1 = Stopped
InChannels2 = Stopped e1
* af
12
[]
C6 : InChannels1 = Stopped
InChannels2 = Stopped e2
* af
21
end Crossover
Figure 3.6: Specification for Crossover
28
CHAPTER IV
SIMULATOR DESIGN AND IMPLEMENTATION
The design of the simulator is based on an object-oriented approach [30].

Since the essence of the object-oriented approach is simulation as a metaphor for
computation, the object-oriented approach was well suited for the task of designing
a simulator. The design of the simulator directly follows the compositional method
presented in the preceding chapter.
In OMNeT++, systems are simulated by specifying simple and compound
modules as discussed in Section 2.3. Three simple modules were designed to capture and represent the behavior of the three building blocks, namely Segment,
Turnaround and Crossover discussed in the preceding chapter. Other modules that
are necessary to support the reconfigurable composition of conveyor systems using
these building blocks were also designed as described in this chapter.
4.1
Overview
To simulate an instance of Coupled Conveyors a user of this simulator must
specify the number of Segments, Turnarounds, and Crossovers in a NED file. In

addition, the user must specify connections between the building blocks, positions
of sensors and actuators on the blocks, and other parameters such as the length of
the entities, length of each building block, the speed of movement, etc.
29
For the purposes of this simulator, an instance of Coupled Conveyors may

consist of any number of:
Entity Sources that inject entities into the conveyor system,
Entity Sinks that consume entities from the conveyor system,
Segments that are represented by the class CCSegment,
Turnarounds that are represented by the class CCTurnaround,
Crossovers that are represented by the class CCCrossover,
Microcontrollers that regulate the operations of a conveyor system,
Mediums that are used for communications between nodes, and
Monitoring Stations that log information about the current state of the conveyor system.
The design and function of each of these will be discussed thoroughly in the
sections below.
4.2
Entity Source
In OMNeT++, events are triggered whenever two modules exchange a mes-
sage. Each entity that traverses through Coupled Conveyors is represented in the
simulator as two messages: the first indicates the beginning or arrival of an entity,
EntityBegin, and the second indicates the end or departure of an entity, EntityEnd .
To initiate the simulation, an EntitySource module generates these messages.
The rate at which entities are injected, the length and type of the entity and configurable parameters that can be specified before the simulation begins.
30
The NED specification for an EntitySource is listed below.

simple Source
parameters:
interval: const,
speed: const,
entityLength: const,
entitiesToGenerate: const,
value: numeric;
gates:
out: out[];
endsimple
The interval parameter specifies the time in seconds between which entities are generated. Speed specifies the speed with which an entity leaves the EntitySource. In the simulator, this phenomenon is represented as two messages the
first being EntityBegin and the second being EntityEnd. The Speed parameters determines the time interval between these two messages. The entityLength parameter
refers to the length of all the entities generated by the EntitySource, and entitiesToGenerate specifies the number of entities the source must generate. A value of -1
will cause the EntitySource to generate entities until the simulation is terminated.
To suit the requirements of various applications, the EntitySource can be parameterized to assign either a specific value or a random value for the entities it
generates. For example, in an application with multiple EntitySources, it is convenient to assign unique values to the entities to make it easier to evaluate entity
latency.
Simple or compound modules can be parameterized by assigning values in
the initialization file. For example, in the following example, the entities that are
injected by a source are assigned integer values between 1 and 10 by drawing these
numbers from a uniform distribution1
1
There are many other random number generators and distributions supported in OMNeT++.
See Section 6.4.4 of the OMNeT++ Manual [27] for a full listing.
31
[Parameters]
factory.source.value = intuniform(1,10);
The assignment of values to entities is useful in simulations of applications
that use Turnarounds and Crossovers. This is because these blocks can alter the
flow of entities and the decision to alter the flow can be made using the value of the
entity. For example, in a package sorting application, it may be necessary to divert
small entities to one output dock and large entities to another dock. Similarly, the
value field can also represent attributes such as weight, size, quality, etc.
4.3
Entity Sink
The EntitySink module sinks or consumes entities that arrive at its input.
Like the EntitySource, this module has been designed to make it convenient to carry
out the simulations. The time at which an entity arrives at the EntitySink is recorded.
By comparing this time to the time at which the entity was injected into the system
by a source, we calculated the entity latency in the conveyor system2 .
4.4
Building Blocks for Coupled Conveyors

The Coupled Conveyors modules are used to model the three different build-
ing blocks: Segment, Turnaround and Crossover. Unlike Source and Sink, they are
compound: built from a hierarchy of submodules. CCSegment, CCTurnaround and
CCCrossover are all similar in design, but differ in the specific parameter values
sent to sub-modules.
OMNet++ supports a rich set of classes that make it easier to collect statistics.
32
module CCSegment
parameters:
x, y: const; // location of the module
gates:
in: entitiesIn[], commIn[];
out: entitiesOut[], commOut[];
submodules:
node: NSASNode
parameters:
moduleType = 1,
x = x,
y = y;
metal: Metal
parameters:
moduleType = 1,
SensorAdaptorType = "SegmentSensorAdaptor",
ActuatorAdaptorType = "SegmentActuatorAdaptor",
InteractorType = "SegmentInteractor";
gatesizes:
entitiesIn[2], entitiesOut[2];
connections nocheck:
for i=0..1 do
metal.entitiesIn[i] <-- entitiesIn[i];
metal.entitiesOut[i] --> entitiesOut[i];
endfor;
commIn --> node.commIn;
commOut <-- node.commOut;
metal.interactorOut --> node.metalIn;
metal.interactorIn <-- node.metalOut;
endmodule
33
The parameters x and y are used to indicate the position of the block in the
grid. The commIn and commOut gates are used for bidirectional communication
with the medium(s), and hence other modules. The entitiesIn and entitiesOut gates
are used to receive and send entities (i.e., EntityBegin and EntityEnd messages).
In the case of CCTurnaround and CCCrossover, the entitiesIn and entitiesOut arrays
contain multiple elements.
All the three Coupled Conveyors modules contain NEANode and Metal as submodules. The NEANode represents the microcontroller with its integrated transceiver
and the software that executes on an NEA node.
Communications Medium
Segment
Node
Transceiver
Microprocessor
LocalActor
Coordinator
Metal
Downstream
Sensor
Lip
Upstream
Sensor
Lip
Sensor
Adaptor
Interactor
Actuator
Adaptor
Motor
Figure 4.1: Modules in a Segment
34
4.4.1 Metal
As shown in Figure 4.1, the Metal module is composed of an Interactor, a
SensorAdaptor, and an ActuatorAdaptor. The sensors are connected through the SensorAdaptor, while the actuators are connected through the ActuatorAdaptor.
The Metal module is used to simulate the mechanical entities of the building
block and their physical interactions with entities. The moduleType parameter is
used to disambiguate between a Segment, Turnaround or Crossover with a value
of 1,2 or 3, respectively, in modules such as LocalActor. The other parameters in
Metal specify the appropriate submodules based on the moduleType. EntityBegin
and EntityEnd messages from upstream blocks in the conveyor system come in to
Metal through entitiesIn gates. Entities leaving the block, i.e. EntityBegin and EntityEnd messages which are sent to downstream blocks, are sent via the entitiesOut
gate. The Interactor sub-module in Metal is connected to the SensorAdaptor and ActuatorAdaptor sub-modules in Metal, and Microcontroller sub-module in Node. Figure
4.1 depicts the relationships between the sub-modules in the building block for
Segment.
The internal details of Metal of a Turnaround, as it appears during the OMNeT++ simulation, is shown in Figure 4.2.
ConveyorLip
ConveyorLip modules are placed in-line between Sensors and the connections
to the entitiesIn and entitiesOut gates. The lip represents the distance on the conveyor from the edge of the belt to the sensor at that end of the belt. The ConveyorLip
module then acts as a simple delay block that entities have to go through before
they get picked up by the sensor. The actual delay time depends on the length of
the lip (defined by a parameter of the module) and the speed of the module.
Interactor
The Interactor handles the physical interactions between the entities and a
block and relays the messages between the sensors and actuators and the Node
35
Figure 4.2: Internals of Metal

module. Due to the differences in behavior between the building blocks, each block
has its own Interactor. This means that the current design supports a SegmentInteractor, a TurnaroundInteractor and a CrossoverInteractor. The Node module uses messages
from the Interactor to obtain current sensor values, to energize local actuators, and
to communicate with other microcontrollers.
4.4.2
Node
The Node is a compound module consisting of Microcontroller and Transceiver
as sub-modules. While these two sub-modules are connected to each other, Microcontroller has a connection to the Interactor sub-module of Metal and Transceiver has
a connection to a Medium.
36
Microcontroller: LocalActor and Coordinator

The Microcontroller serves an interface to the LocalActor and Coordinator modules. These represent a functional separation in the software of the Microcontroller.
The LocalActor is responsible for responding to local events coming in from the
Interactor in Metal and reacting to information about remote events from the Coordinator. In contrast, the Coordinator communicates with a Coordinator in another
Node via the Transceiver. These interactions are necessary to learn about incoming
entities, perform network services, fulfill requests for diagnostic information, etc.
Transceiver
The Transceiver module provides a place to model the properties of a specific
radio used by the a NEA node. Currently the simulator has been designed assuming
an ideal transceiver and ideal MAC layer. It is possible to account for MAC delays
by connecting a Transceiver to a Medium via a Channel supported in OMNeT++.
The support for channel allows one to specify attributes such as bit-error rates,
propagation delay, and bandwidth. The date rate of a Transceiver is specified by the
bytesPerSecond parameter. All message from Node are sent by a Transceiver as Packet
messages. These messages contain fields for send and receive time, source position,
source module type, etc.
A simple variable back-off Media Access Control (MAC) protocol is implemented in Transceiver. If the communications medium is in use when a Transceiver
attempts to send a message, it will reattempt to send it after the time it would normally take to send the packet based on the transceivers data rate, this is referred to
as the transmit time. The time to wait before attempting to send again is referred
to as the retry time and is defined as
retryT ime = transmitT ime numberOf Attempts + unif orm(0, transmitT ime)
Here uniform refers to an OMNeT++ function that generates a uniform random
number in the range [0, transmitTime]. The reason for the added randomization is
to prevent multiple nodes contending for the channel to repeatedly contend at the
37
same times. The integration of other MAC protocols with this simulator is discussed
as a part of future work in Chapter VI.
4.5
Medium
The Medium acts as a local hub for nodes that can communicate to each
other. Each nodes Transceiver is connected to a Medium module, messages sent to

the Medium are ideally repeated to every other node connected to that medium. It
is possible to create new mediums that utilize some form of wireless propagation
model such that some messages are lost, based on their location relative to the
transmitter and some probability.
To create multi-hop networks, it is necessary to use many Medium modules
and connect Tranceivers to the Mediums appropriately. For communication to occur
between two hops at least one node would need to be connected to two or more
mediums.
4.6
Monitoring Station
The MonitoringStation is a human interaction device and displays the status
of the Coupled Conveyors instance. In the simulator, a monitoring station is a

module that records all information it receives. It periodically requests Monitoring
Messages from all the NEA nodes. This information is written to a file at the end of
the simulation.
4.7
Building an Application
The simulator becomes configured for a specific instance of Coupled Con-
veyors by putting together the appropriate modules and specifying their parameters. There is some variety in the exact procedure for setting up an application,
depending on how or where the user wants to define parameters or what optional
statements they want to include. The general steps to configuring the simulator for
a Simple Conveyor System shown in Figure 4.3 are outlined in this section.
38
Start off by creating a new Network Description (NED) file and including in
it the CCModules.ned file using the command import "CCModules";.
Next, create a new compound module that will hold all the other modules
for the simulation. This should include at least one source, sink and medium and
several Coupled Conveyors modules; a monitoring station is optional. Figure 4.3
shows that the Simple Conveyor System requires five Segments, one Turnaround
and one Crossover. The Coupled Conveyors modules will be declared in three arrays, one for each type. Three parameters are added to specify the size of each of
these arrays. The entitiesIn and entitiesOut gatesizes are set to 2 for Crossovers
and Turnarounds, since they both have two input and two output ports, and set to
1 for Segments.
module SCS
parameters:
numSegments: const,
numTurnarounds: const,
numCrossovers: const;
submodules:
medium : CommMedium;
ccsegments : CCSegment[numSegments];
gatesizes: entitiesIn[1], entitiesOut[1];
ccturnarounds : CCTurnaround[numTurnarounds];
cccrossovers : CCCrossover[numCrossovers];
source : Source;
sink : Sink;
endmodule
Now, add a connections section to the SCS module. Connect the Coupled Conveyors modules together as needed along with the sources and sinks; all Coupled
39
Conveyors modules should be wired to the same CommMedium, since only one is
used this example. These connections are made with lines like the following:
source.out++ --> ccsegments[0].entitiesIn[0];
ccsegments[0].entitiesOut[0] --> ccsegments[1].entitiesIn[0];
In the above section of code, a source module is connected to the input port
of Segment0. On the second line, the output port of Segment0 is connected to
input port of Segment1. Many more connections need to be established in order to
construct the Simple Conveyor System shown in Figure 4.3, but those lines will be
omitted for brevity.
OMNeT++ allows for for loops in NED files, these can be handy in situations
like:
entitiesIn[1] are referred to as Port A and Port B while entitiesOut[0] and
entitiesOut[1] are referred to as Port D and Port C, respectively.
for i=0..numSegments-1 do
medium.in++ <-- ccsegments[i].commOut
medium.out++ --> ccsegments[i].commIn
endfor;
This code connects every Segment to the medium in only four lines. Similar
loops are used to connect the Turnarounds and Crossovers to the medium. After
this code is added to the SCS module, and the monitoring station is connected to
the medium, a network needs to be defined for the SCS with parameter values with
the sizes of the arrays.
network scs : SCS
parameters:
numSegments = 5,
numTurnarounds = 1,
numCrossovers = 1;
endnetwork
40
From here the NED file is finished. Now all the remaining unspecified parameters and simulation settings need to be defined in the omnetpp.ini file. OMNeT++ is versatile in the way that it allows parameter settings in the omnetpp.ini
file, pattern matching can be used to greatly reduce the number of configuration
lines needed.
[Parameters]
scs.ccsegments[0].metal.motorSpeed = 5;
scs.ccsegments[*].metal.motorSpeed = 5;
scs.*.metal.motorSpeed = 5;
For example, in the first line above only the motorSpeed of Segment0 is set.
In the second line, the motorSpeed for all Segments is set and in the third line, the
motorSpeed for all Segments, Turnarounds and Crossovers is set.
Once all the simulation settings are specified, everything is now in place for
simulation. Simulation results for the Simple Conveyor System, and other applications of Coupled Conveyors, are discussed in the next chapter.
S0
S1
S4
Src
Sink
S2
0,1
S3
H1
C0
Test
Factory
0,0
1,0
4,0
SrcB
SinkB
Figure 4.3: Simple Conveyor System
41
CHAPTER V
APPLICATIONS AND RESULTS
This chapter presents simulation results that demonstrate the effectiveness

of the simulator and the Coupled Conveyors approach.
It was necessary to evaluate several aspects of the new simulator. First, it
was necessary to show that the behavior of the building blocks are as expected.
This was accomplished through a series of simulations based on the Simple Conveyor System described in Section 4.7 of the preceding chapter. Second, it was
necessary to demonstrate that the Coupled Conveyors approach is not restricted to
a particular conveyor system. Section 5.3 presents conveyor systems for an Inspection Station. This system is used to demonstrate how the simulator is useful for
evaluating fault tolerance and communications. Section 5.4 presents a conveyor
system for a Package Sorting application. This system was used to demonstrate the
benefits of reconfigurability. Since OMNeT++ is a robust platform that has been
extensively tested in a variety of simulation environments, and because the design
of the simulator did not involve new, or extensively revised, data structures, traditional measures such as computation time and memory used were not considered.
5.1
Basic Simulation Setup

All the simulations in this chapter are based on a similar set of values for the
parameters. Examples of such parameters are length of the building block, entity
length, and speed of movement. Table 5.1 shows a list of parameters and their
values.
With reference to Table 5.1, note that the length of a building block does not
42
Parameter
Entity Length
Belt/Motor Speed
Lip Length
Segment Length
Turnaround Length
Turnaround Leg Length
Turnaround Leg Width
Crossover Length
Crossover Arm Offset
Crossover Arm Travel Distance
Crossover Arm Speed
Transceiver Data Rate
Monitoring Station Polling Interval
Value
1.0 unit
5.0 units/sec
5.0e-2 units
10.0 units
10.0 units
1.0 units
1.0 units
12.0 units
6.0 units
5.0 units
5.0 units/sec
2.4 kbytes/sec
Every 5 seconds
Table 5.1: Parameters Values

include the lip length on its port(s). The Crossover Arm Offset is the distance from
Port A, along the end-segment, where the crossover is located. The Crossover Arm
Travel Distance is the distance between the two end-segments that the arm travels.
The data rate chosen for the transceiver is currently based on Crossbows Mica2Dot
mote, a commonly used hardware platform [31].
5.2
Behavior of Building Blocks

The results in this section are based on the Simple Conveyor System de-
scribed in Section 4.7. This is a simple conveyor system that has been designed to
demonstrate the simulator. Using this system, simulations were executed to verify
the functionality of Segment, Turnaround and Crossover.
5.2.1 Baseline Experiment
Purpose:
Establish a baseline performance to compare results in this
chapter.
The Simple Conveyor System was simulated using the parameters shown in Table
5.2. The Interval for SrcB was chosen to ensure that all the entities from SrcB were
not always coming out at the same times as entities from Src. Entities injected by
43
Src are assigned random Values between 1 and 15 while the entities injected by
SrcB are assigned values between 6 and 20. The range parameters shown in Table
5.2 for Turnaround and Crossover blocks, were chosen to allow entities from both
Src and SrcB to arrive at either Sink or SinkB .
Parameter
Simulation Time
Src
Interval
Value
SrcB
Interval
Value
Turnaround Deflect Range
Crossover AD to BC Range
Crossover BC to AD Range
Value
100.0s
1.0
intunif orm(1, 15)
2.2
intunif orm(6, 20)
11. . . 20
15. . . 20
0. . . 0
Table 5.2: Baseline Experiment Parameters

As shown in Figure 4.3, there are five unique paths in the Simple Conveyor
System. These paths are:
1. Src, S0 , S1 , T0 , S4 , Sink
2. Src, S0 , S1 , T0 , S3 , C0 , SinkB
3. SrcB , C0 , S2 , T0 , S4 , Sink
4. SrcB , C0 , SinkB
5. SrcB , C0 , S2 , T0 , S3 , C0 , SinkB
The end-to-end entity travel time is the time required by an entity to traverse
over the conveyor system from a source to a sink. Figure 5.1 shows the end-to-end
entity travel times for each of the five paths above. It can be noticed that the entities
cluster along the y axis at five different values. Each such value corresponds to
the time required by entities to travel along one of the above paths. The entities
arriving at SinkB require 3.62s along Path 4. The time along Path 1 and Path 3 are
8.28s and 8.68s, respectively. Entities traversing along Path 3 require more time
44
because the Crossover length is 12 units while Segment length and Turnaround
length are 10 units. The entities that traversed along Path 2 and Path 5 required
10.7s and 11.1s to arrive at SinkB .
TestFactory Endtoend Part Travel Time
Part Travel Time (s)
10
20
40
60
80
Part Sink Time (s)

Endtoend Part Travel Time in factory.sink (omnetppCrossover12.vec)
Endtoend Part Travel Time in factory.sinkB (omnetppCrossover12.vec)
Figure 5.1: Simple Conveyor System - End-to-end entity travel times.

In this simulation, Src injects entities with integer values in the range [1, 15]
and SrcB injects entities with integer values in the range [6, 20]. Because of the
parameter settings shown in Table 5.2, Turnaround T0 deflects all entities that have
values in the range [11, 20]. Consequently, only entities with values in this range
should arrive at SinkB ; further, entities with values in the range [1, 10] should arrive
at Sink. Figure 5.2 shows the values of entities that arrive at Sink and SinkB . It
may be noticed that the entities arrive at the appropriate EntitySink as expected.
The simulator also provides data on packet transmission and communication
between the NEA Nodes. All packets are fixed in size for the purpose of comparison.
In this simulation, every node can hear and communicate with every other node.
Figure 5.3 shows the packet transmission time. Most packets take 4.0e-2
seconds to transmit, however, large spikes are visible every 5.0s. These spikes are a
result of the monitoring stations polling, which is set to every 5.0 seconds; because
45
Test Factory Entity Values

20
Entity Value
15
10
20
40
60
80
Simultation Time (s)

Part Values in factory.sink (omnetpp.vec)
Part Values in factory.sinkB (omnetpp.vec)
Figure 5.2: Simple Conveyor System - Entity Values.

every node attempts to respond to the monitoring station request immediately after
it is received, all of the nodes contend for the channel at the same time.
The packets that required more than 4e-2 seconds are those that had to wait
because the medium was busy when the node wanted to transmit. The packet times
peak at 0.13s as a result, 0.09s more than normal. In addition to the spikes, there
were a number of packets that took between 4.67e-2 seconds and 5.33e-2 seconds,
these are the coincidental result of two or three nodes contending for the channel
to send messages.
5.2.2 Experiment 1 - Segment Behavior
Purpose: Demonstrate that the Segment behavior in CCSegment is as
expected.
The behavior of Segment was verified by ensuring that entities traversing the
conveyor system arrive at the expected EntitySink. By varying parameters such as
speed of the block and length of the entity, it was established that the end-to-end
entity travel time is as expected.
46
Packet Transmission Duration (s)
Test Factory Packet Transmission Times
0.1
0.05
20
40
60
80
Time (s)
Figure 5.3: Simple Conveyor System - Packet Transmission Times.

In this experiment, the deflector on T0 and crossover arm of C0 were disabled.
The parameters used for this experiment are shown in Table 5.3.
Parameter
Simulation Time
Src
Entities To Generate
Interval
Value
Value
150.0s
100
1.0
intunif orm(1, 15)
0. . . 0
0. . . 0
0. . . 0
Table 5.3: Parameters for Validating Segment

The results in Table 5.4 show that the entities are injected at an EntitySource
as expected. The expected number of entities arrive at each EntitySink. All entities require the same amount of time to traverse the Simple Conveyor System, as
expected because there is only one path.
Additional simulations were executed to verify the effects of changes in Motor
Speed and Entity Length. It is desirable for the entity travel time to be cut in half
47
Property
Src Entities Generated
SrcB Entities Generated
Sink Entities Consumed
SinkB Entities Consumed
Entity Travel Time
Value
100
0
100
0
8.28s
Table 5.4: Validating the Segment Simulation Results

when the motor speed is doubled. Similarly, increases in entity length should yield
increases in travel time. The results in Table 5.5 confirm this behavior.
Motor Speed (units/sec)
5.0
5.0
5.0
5.0
10.0
10.0
10.0
10.0
Entity Length (units)

1.0
2.0
6.0
20.0
1.0
2.0
6.0
20.0
Entity Travel Time (s)

8.28
8.48
9.28
12.08
4.14
4.24
4.64
6.04
Table 5.5: Effects of Changing Speed and Entity Length

It is clear from Table 5.5 that the end-to-end travel times are decreased by
half when the speed is doubled. However, the response to changes in entity length
warrant further explanation. The simulator currently ignores the effects of friction
and other physical phenomena and calculates the time required by an entity to
traverse the block, with length distance time = distance/speed. Note that an entity
of length 1 unit requires 1.0/5.0 = 0.2 seconds to traverse the block when the
speed is 5.0 units/second. Along Path 1, the entity will traverse 3 Segments and
a Turnaround, each of which is 10.0 units in length. In addition, the entity must
traverse lip lengths of 0.05 units on each side of a block. Thus, the effective length
of each block is 10.0 + 2 0.05 = 10.1 units the total distance across the four blocks
in Path 1 is 4 10.1 = 40.4 units. The total travel time is then
40.4units
5.0
= 8.08 seconds
without accounting for the entity length.

The entity travel time reported by the simulator is measured from the time
the an entity leaves an EntitySource until the entity arrives at an EntitySink. Con48
sidering this more closely, the time reported is the time when the front of an entity
leaves an EntitySource and the back of the entity arrives at an EntitySink. Consequently, the time reported accounts for the length of the entity when it traverses
the distance along some path. After accounting for the entity length, i.e., adding
one entity length to the length of traversal along a path travel, the time required is
8.08 + 0.2 = 8.28 seconds, which agrees with the results shown in Table 5.5.
5.2.3
Experiment 2 - Turnaround Behavior

Purpose: Demonstrate that the Turnaround behavior in CCTurnaround
is as expected.
The code that is used in CCTurnaround for simulating the traversal of an en-
tity is the same as that used in the CCSegment. Consequently, this experiment was
focused on demonstrating the unique attributes of the Turnaround. The experiment
was designed to verify that the deflector will only deflect values in the specified
range. Further it is demonstrated that the Turnaround implements mutual exclusion to prevent entities from arriving via Port A and Port B simultaneously. The
effect of this mutual exclusion on the performance of the conveyor systems is also
demonstrated.
The topology shown in Figure 4.3 is used with C0 disabled. The Turnaround
T0 is specified to deflect entities with values in the range [11, 20]. The parameters
used for this are shown in Table 5.6. In this simulation, entities may traverse along
Path 1, Path 2, Path 3, and Path 5 only since Path 4 is disabled.
The results of this simulation are shown in Table 5.7. It can be noticed that,
of the 200 entities generated, all 200 arrived at an EntitySink. The Turnaround
deflected 109 entities toward SinkB , while the remaining 91 arrived at Sink.
Figure 5.4 shows the values of entities that arrived at each EntitySink. This
confirms that only entities with values in the range [1, 10] arrived at Sink and all
the entities deflected to SinkB had values in the range [11, 20] as expected.
Figure 5.5 shows that the end-to-end travel times were 8.28, 8.68, 10.7 and
11.1s for entities traversing along Path 1, Path 2, Path 3, and Path 5, respectively.
49
Parameter
Simulation Time
Src
Interval
Value
SrcB
Interval
Value
Value
250.0s
100
1.0
intunif orm(1, 15)
100
2.2
intunif orm(6, 20)
11. . . 20
0. . . 0
0. . . 0
Table 5.6: Parameters for Validating the Turnaround

Property
Src Entities Generated
SrcB Entities Generated
T0 Entities Deflected
Value
100
100
91
109
109
Table 5.7: Overall Simulation Results

The remaining entities arrive after either 8.88s (at Sink) or 11.3s (at SinkB ). These
entities required additional time because of the mutual exclusion in T0 . To confirm
this effect, the injection rate at SrcB was increased to one entity every 0.72s. Figure 5.6 shows that the end-to-end travel times of a larger number of entities increase. Table 5.8 shows the average travel times and compares them to the average
times from Figure 5.5. For example, the change in generation interval from 3.0 to
0.72, then resulted in an increase in entity travel time by a factor of approximately
(11.02/10.88 + 8.46/8.37)/2 1.012 or 1.2%.
SrcB Generation Interval
3.0
1.37
8.9e-1
7.2e-1
Avg. Travel Time (Sink) Avg. Travel Time (SinkB )

10.88
8.37
10.94
8.39
10.99
8.45
11.02
8.46
Table 5.8: Average End-to-end Travel Time Per Sink
50
Validating the Turnaround: Entity Values Per Sink Time

20
Entity Value
15
10
100
200
Simulation Time (s)

Part Values in factory.sink (VT1 omnetpp.vec)
Part Values in factory.sinkB (VT1 omnetpp.vec)
Figure 5.4: Entity Arriving at Sinks

It may be noticed in Figure 5.4 and Figure 5.5 that the number of entities
arriving per second decreases significantly, shortly after 100s of simulation time.
Since only 100 entities are generated from Src and they generated every 1.0 second then Src stops after 100s, that is when its 100th entity is generated. This is
confirmed in Figure 5.4 as no more entities valued [1, 5] are arrive after 110s. Entities with values in the range [1, 5] are exclusive to Src since SrcB only generates
entities with values in the range [6, 20].
15. . . 20
1. . . 10
11. . . 20
1. . . 20
0. . . 0

150
98
91
0
200

50
102
109
200
0
Table 5.9: Turnaround with Varying Deflect Ranges

The simulation was repeated with T0 deflecting entities with different values.
As expected, when the deflector was set to 1 . . . 20, all entities arrived at SinkB .
When the deflector is disabled, all entities passed through the Turnaround and ar51
Validating the Turnaround: Entity Travel Times
Entity Travel Duration (s)
11
10
100
200
Simulation Time (s)

Endtoend Part Travel Time in factory.sink (VT1 omnetpp.vec)
Endtoend Part Travel Time in factory.sinkB (VT1 omnetpp.vec)
Figure 5.5: End-to-end Entity Travel Times

rived at Sink. When the deflection range was set either at 1 . . . 10 or 11 . . . 20,
approximately half the entities arrived at each sink, as expected.
5.2.4 Experiment 3 - Crossover Behavior
Purpose: Demonstrate that the Crossover behavior in CCCrossover is
as expected.
As in the case of the Turnaround, the range of values that must be moved
will be changed to determine whether the expected percentage of entities are actually moved by the crossover arm. Since the actuators on the end-segments of a
Crossover are deenergized every time an entity is moved, the travel time of any
other entities traversing over the end-segments will be increased.
In this experiment, Src and the deflector for T0 will be disabled, allowing
entities to follow only paths 3 and 4. The Crossover range for C0 will be varied to
observe the different results. Table 5.10 lists the simulation parameters used.
The results of this simulation are shown in Table 5.11. The number of entities
at each sink correspond to the fraction of the range of entities that were crossed
52
Validating the Turnaround: Increased Port A/B delays

Endtoend Part Travel Time in factory.sink (omnetpp.vec)
Endtoend Part Travel Time in factory.sinkB (omnetpp.vec)
11
10
50
100
Simulation Time (s)
Figure 5.6: Effects of Mutual Exclusion

Parameter
Simulation Time
SrcB
Interval
Value
Value
450.0s
100
4.0
intunif orm(1, 20)
0. . . 0
Table 5.10: Parameters for Validating the Crossover

over. Columns four and five of the table show the times it took entities to travel
through Path 3 and 4, respectively. It is notable that these times are the same
regardless of the crossover range.
When a Crossover needs to cross an entity from one end-segment to another,
it is necessary for both end-segments to stop while the entity is traveling. Since
both end-segments stop, any entities that are on the end-segments are delayed. If a
larger percentage of the entities going through the Crossover are crossed over, then
the average travel time should increase.
The travel time does not increase in Table 5.11 because the entity generation
interval (every 4.0 seconds), is too large. The distance from Port A to the arm is
6.0 units and the distance from the arm to Port C on the other side is also 6.0 units:
53
then the total distance traveled for Path 4, from source to sink, is 6.0 + 5.0 + 6.0 +
1.0 + 0.05 + 0.05 = 18.1 units and hence the travel time is 18.1/5.0 = 3.62 seconds.
The results in Table 5.11 confirm that this is the case.
Since the arm travel distance, as defined in Table 5.1, is 5.0 units, the arm
speed is 5.0 units, and the entity length is 1.0 unit then it will take an entity
(5.0 + 1.0)/5.0 = 1.2 seconds to fully cross between the two end-segments. As a
result, any other entities on the Crossovers end-segments are delayed by up to 1.2
seconds. However, in this case, since the time between the end of one entity and
the beginning another is greater than 3.62 seconds, no other entities are on the
Crossovers end-segments at the same time, and hence, none are delayed.
0. . . 0 (0%)
1. . . 20 (100%)
1. . . 5 (25%)
1. . . 10 (50%)
1. . . 15 (75%)
Sink Entities
100
0
75
48
26
SinkB Entities
0
100
25
52
74
Path 3 Path 4
8.68s
- 3.62s
8.68s 3.62s
8.68s 3.62s
8.68s 3.62s
Table 5.11: Overall Simulation Results

In order to see the effect of the delay from crossing over upon the entity
travel times, the simulation was run at faster entity generation intervals for SrcB
so that multiple entities would be on the Crossover at the same time. These results
are in Table 5.12. For an interval of 1.0s, crossing entities valued [1, 10] causes an
additional 0.28s of latency on Path 3 and 0.21s on Path 4.
5.3
Inspection Station
Figure 5.7 shows an instance of Coupled Conveyors that is useful for for
material inspection and/or sorting [2]. There are 18 Segments, 4 Turnarounds and
one Crossover. For example, port D of Turnaround T4 is embedded at grid location
(1,1), and port A of Turnaround T2 is at grid location (5,3). Crossover C1 is at grid
location (3,3); HCI devices H1 , H2 , and H3 are at grid locations (1,0), (3,4) and
54
0,5
H2
0,4
S1
S2
S3
S4
S5
S8
S7
S6
0,3
T1
T2
C1
S10
S9
0,2
Manual
Inspection
S12
S11
S16
S15
0,1
S13
T4
S18
S14
S17
T3
North
H1
0,0
H3
1,0
2,0
3,0
4,0
Figure 5.7: An Inspection System
55
5,0
6,0
SrcB Interval
1.0s
1.0s
1.0s
1.0s
1.0s
1.5s
1.5s
1.5s
1.5s
1.5s
0. . . 0
1. . . 5
1. . . 10
1. . . 15
1. . . 20
0. . . 0
1. . . 5
1. . . 10
1. . . 15
1. . . 20
Path 3
8.68
8.72
8.96
9.18
8.68
8.78
9.00
9.01
-
Path 4
3.65
3.83
4.10
4.62
3.84
3.91
4.02
4.06
Table 5.12: Validating the Crossover - Entity Latency

(5,0), respectively1 .
Entities come in to the system via S6 (at port A of T2 ) or S17 (port A of T3 ).
Entities leave the system via port D of T4 or via S1 (at port D of T1 ). Those coming
in via S6 may be moved either along the path
T2 , S7 , S8 , S9 , S10 , T1 , S1
or along the path
T2 , S16 , T3 , S14 , S13 , T4 , S11 , T1 , S1 .
Entities may be deflected for re-inspection via port C of T3 . Defective or oversized
material that are likely to damage the inspection devices along the subpath S10 , T1
may be diverted using C1 . Entities coming into T3 can be moved along the subpath
T3 , S14 , S15 , or deflected at port C of T3 for manual inspection. Manually inspected
entities may be re-inserted into the system via port B of T4 . The HCI devices are
used to monitor the status of all modules and the operator panels can be used to
issue commands such as start, stop, or force manual inspection for all entities over
a duration of time.
1
In addition to the sensors and actuators on the building blocks such an application will require
additional devices such as cameras, RFID tags and scanners, weighing scales, etc. to inspect the
entities that are being moved.
56
5.3.1 Simulation Setup

For simulation purposes, EntitySources were placed at S6 and S17 and EntitySinks were placed at S1 and S18 . To simulate the manual inspection of entities, a
long slow segment, S0 , is placed between S1 5 and S1 2 to represent the time required
manually inspect entities.
A numbering scheme for entity values was devised to adapt this application
to the simulator. The source at S6 , called source6 , generated entities with values 1
. . . 15, while source17 generated entities with values 6 . . . 20. Entities with values
> 10 were flagged for manual inspection. To accomplish this objective, T2 deflected
entities 10 and other entities passed through to T3 . At T3 , entities > 10 were
deflected to S15 and arrived at the manual inspection area. These entities returned
through T4 and exited the system through sink18 . Entities from source17 with values
10 passed through T4 ; these entities were deflected back to S1 1.
Entities through C1 from the S8 , S7 sub-path are randomly crossed over for
inspection along the S4 , S5 sub-path 10% of the time. Similarly, 10% of entities
through T1 are randomly deflected onto S2 for additional inspection. This randomization was used to reflect situations where the entity values could not represent all
the desired properties of the entity.
Table 5.13 shows the parameters that were used to achieve the above described behavior. The application as it appears in the simulator is shown in Figure
5.8, the modules were placed automatically using OMNeT++s layout algorithm.
Table 5.14 shows the results gathered from simulating the Inspection Station. These
results were analyzed to confirm that the correct number of entities are conserved
in the system, and in each Turnaround and Crossover.
From the 50 entities generated by source6 and the 25 entities from source17 ,
75 generated total, 42 arrived at sink1 and 33 arrived at sink18 ; these add up to the
75 entities that were generated. This verifies that all the entities that entered the
system eventually left the system.
57
Parameter
Simulation Time
Monitoring Message Request
For source6 :
Interval
Value
For source17 :
Interval
Value
T1 Deflect Range
T2 Deflect Range
T3 Deflect Range
T4 Deflect Range
C0 BC to AD Range
Value
110.0s
Every 5 seconds
50
1.0
intunif orm(1, 15)
25
3.5
intunif orm(6, 20)
intunif orm(0, 2)
1. . . 10
11. . . 20
1. . . 10
intunif orm(0, 2)
Table 5.13: Inspection Station Parameters

Property
sink1 Entities Consumed
sink18 Entities Consumed
C0 Entities Crossed BC to AD
Value
42
33
5 out of 47 (10.63%)
47 out of 62 (75.81%)
33 out of 40 (82.50%)
7 out of 40 (17.50%)
7 out of 52 (13.46%)
Table 5.14: Inspection Station Simulation Results

Since the only entities coming through T3 that are valued 10 come from
source17 , exactly 25 entities are from source17 and a third of these are in the range
[6, 10]. This implies that, on average, about 8/3 entities should pass through T3
undeflected. From the simulation data it was seen that 7 entities actually did go
undeflected through T3 . These same 7 entities were then deflected out of T4 , while
the remaining entities left the system through sink18 . This accounts for the entities
entering the system through T3 and exiting through T4 .
Consider that T2 deflected 47 entities to the sub-path S7 , S8 , S9 , S10 . The
Crossover, C1 , moved 7 of these entities from S9 to S3 , while T1 deflected 5 of its
entities; this results in 12 entities along the sub-path S4 , S5 , T2 , entering in port B of
58
T2 . Since source6 generated 50 entities that entered port A, 50 + 12 = 62 is the total

number of entities that went through T2 as confirmed by the simulation.
Out of the 47 entities that went through T1 , 7 entered through port A from
T4 s port C and the remaining 40 entered from port B. Since 5 entities were deflected, 47 5 = 42 entities left to S1 and then sink1 , which corresponds to the
number of entities sink1 reported to have destroyed. This analysis verifies the results shown in Table 5.14
Figure 5.8: Inspection Station Screenshot
5.3.3
Experiment 4 - Communication
Purpose: Demonstrate the use of the simulator to evaluate communications in a realistic application of Coupled Conveyors.
Modeling the network communication between NEA Nodes is a crucial as59
pect of this simulator since Coupled Conveyors relies upon this connectivity for all
control and monitoring messages. A node that is connected to a Medium broadcasts
every message that must be sent to every other node on that medium, regardless
of whether or not the message was intended for the receiving node. With a large
number of nodes this can create significant overhead in the microcontroller, as the
receiving node needs to check every packet to see if it was the intended recipient.
Also, no two nodes can successfully transmit messages on the same medium at the
same time, so MAC delays will increase with the number of nodes on the medium.
It was expected that not all NEA nodes will be able to, or need to, communicate with every other node. The were divided among a number of Medium modules,
where some nodes may be connected to multiple Mediums. In this experiment, a
reduction in MAC-related packet latency was observed as a result of distributing
the nodes among a number of mediums. The parameters shown in Table 5.13 were
used for this experiment.
Number of Mediums
One
Two
Four
Modules per Medium

24
14.5
8.5
Mean Packet Latency (s)

1.01e-1
9.3e-2
7.6e-2
Table 5.15: Inspection Station Experiment 4 Results

First the simulation was executed with all nodes connected to a single medium
and the average packet latency was recorded. The simulation for two mediums was
carried out by connecting all nodes above the y = 1.5 line to one medium, and the
nodes below it to another. Bordering nodes, S11 , S12 , S15 , andS16 , were connected to
both mediums. The simulation for four mediums was done by dividing the Inspection Station into quadrants formed by the lines y = 1.5 and x = 3.0. Once again,
nodes bordering two or more quadrants were connected to multiple mediums.
The results are listed in Table 5.15. The second column shows the average
number of nodes attached to each medium, including the border nodes. As expected, the average packet latency decreases with the introduction of additional
mediums. With four Mediums, the packet latency for the Inspection Station reduced
packet latency by 25%.
60
5.3.4 Experiment 5 - Fault Tolerance

Purpose: Demonstrate the use of the simulator to inject faults and evaluate their effects on the performance of the conveyor system.
The simulator can be configured to generate faults within a Segment, Turnaround
and Crossover. In the Inspection Station application, faults may be caused, for example, by materials getting stuck on the conveyors and causing blockage; such
faults are usually resolved by an employee manually dislodging the material. Such
faults effectively disable the belt motors for a specified amount of time and occur
based on a specified probability. This experiment showed that the effects of faults
on the average end-to-end travel time of entities. The parameters shown in Table
5.13 were used for this simulation.
The Inspection Station was simulated using a varying number of fault probabilities, the percent chance is per entity per conveyor module. The duration of the
fault was fixed at 6.5 seconds. Table 5.16 shows the results.
Fault Probability
0%
0.1%
0.5%
0.6%
1%
2%
5%
20%
Mean Entity Travel Time (s)

19.81
20.50
20.66
21.44
22.55
23.50
23.73
24.50
Table 5.16: Inspection Station Experiment 5 Results
5.4
Package Sorting System

Figure 5.9 shows an instance of Coupled Conveyors useful in a package sort-
ing application [2]. There are 22 Segments, eight Turnarounds and one Crossover.
Although some Turnarounds such as T1 , T2 , T3 and T8 appear to be different from
other Turnarounds, all the Turnarounds have two input ports and two output ports.
The behavior of these Turnarounds are not different from the behavior of other
61
Figure 5.9: A Package Sorter

Turnarounds. As an example, packages arrive at a warehouse from five input docks,
I1, I2, , I5. The objective of the application is to sort the packages into three
categories - Small, Medium and Large. As the packages move on the blocks, the part
deflectors on Turnaround modules move to route the packages to different destinations.
A large package that arrived at dock I5 would move along the path
S2 , T1 , S6 , T2 , S13 , S15 , T6 , S21 , S22 , T8 .
Similarly a small packet arriving at dock I2 would move along the path
S18 , T5 , S20 , T6 , S16 , S14 , T3 , S10 , T4 .
5.4.1 Simulation Setup
The simulator is configured as shown in Table 5.17. Small, Medium and Large
entities are modeled by entities valued 1 . . . 10, 11 . . . 20, and 21 . . . 30, respectively.
The deflection and cross over ranges for T1 . . . T8 and C0 are defined as necessary to
ensure that the properly valued entities arrive at the correct sinks.
62
Parameter
Value
Simulation Time
100.0s
For sourceI1 . . . sourceI5 :
Parts To Generate
30
Interval
1.0
Value
intunif orm(1, 30)
T1 Deflect Range
11. . . 30
T2 Deflect Range
21. . . 30
T3 Deflect Range
1. . . 10
T4 Deflect Range
11. . . 30
T5 Deflect Range
n/a
T6 Deflect Range
1. . . 20
T7 Deflect Range
11. . . 20
T8 Deflect Range
21. . . 30
C0 AD to BC Range
11. . . 30
C0 BC to AD Range
1. . . 10
Table 5.17: Package Sorting Simulation Parameters
The number of entities that arrived at each sink along with the amount of
entities that were deflected by Turnarounds or crossed by the Crossover are reported
in Table 5.18.
The total number of entities that arrived at a sink, 44+54+53 = 150, matches
the number of entities generated by all five sources, 5 30 = 150. This shows that
no entities were lost in the simulation. No entities were deflected by T5 because its
deflector is disabled. The Turnaround, T4 deflected 0 entities because all Medium or
Large entities are directed away from it by the other Turnarounds and the Crossover.
Similarly, T7 and T8 deflect all entities because only Medium and Large enter the
respective Turnarounds.
Figure 5.11 shows the values of all entities that arrived at each sink. It confirms that the topology and the configuration correctly directed Small, Medium, and
Large entities to sinkSmall , sinkM edium , and sinkLarge , respectively.
The mean travel times for entities that arrived at each sink are plotted in
Figure 5.12. It suggests that Small entities have the shortest paths, while Medium
and Large entities have paths that are somewhat longer.
63
Figure 5.10: Package Sorting Simulation Screenshot

5.4.3
Experiment 6 - Topology Changes

Purpose: Demonstrate reconfigurability using the simulator.
Suppose that in some seasons a larger number of Small entities are expected.
Such a demand can be met by using additional pathways from the loading docks
to the sinkSmall . One such option is to replace S8 with a new Turnaround, T9 , and
connect Port C of T5 to Port B of T9 via two new segments, S24 and S25 . This forms
a new pathway allowing Small entities to flow toward sinkSmall from sourceI1 and
sourceI2 , reducing the load on T6 . Formerly it was T6 that handled all Small and
Medium sized entities. In this experiment, the Package Sorter was simulated with
these topology changes to observe the impact that reconfiguration has upon the
travel time of the entities.
The simulation results in Table 5.19 show small improvements in mean travel
time for all entities. This suggests that too much traffic through T6 was slowing
down a lot of entities.
64
Property
sinkSmall Entities Arrived
sinkM edium Entities Arrived
sinkLarge Entities Arrived
T1 Deflected
T2 Deflected
T3 Deflected
T4 Deflected
T5 Deflected
T6 Deflected
T7 Deflected
T8 Deflected
C0 Crossed AD to BC
C0 Crossed BC to AD
Small Travel Time
Medium Travel Time
Large Travel Time
Value
44
54
52
21 out of 45
31 out of 66
20 out of 74
0 out of 44
0 out of 60
39 out of 91
54 out of 54
52 out of 52
21 out of 60
7 out of 60
16.52s
18.31s
18.94s
Table 5.18: Package Sorter Simulation Results

Property
Small Travel Time
Medium Travel Time
Large Travel Time
Value
16.27s
17.93s
18.39s
Table 5.19: Reconfigured Package Sorter Results

5.5
Discussion
Results in the preceding sections of this chapter show that the building blocks
of Coupled Conveyors were simulated correctly. Experiment 1 validated the behavior of the Segment module in three ways. Entities that entered a series of segments
were shown to have eventually left. The amount of time for an entity to travel
through the system was manually calculated and matched with the simulation results. Changes in motor speed and entity length yielded the correct responses to
entity travel time.
Experiment 2 showed that the Turnaround module is functionally correct.
First, the deflector was tested, and it was confirmed that only the entities within
the specified deflection range were deflected. Then the entity travel times were
analyzed and shown to be related to the four possible paths through the system.
65
Package Sorter Entity Values at each Sink

30
Entity Value
20
10
20
30
40
50
Simulation Time (s)

Part Values in pkgSort.sinkLarge (PkgSort omnetpp.vec)
Part Values in pkgSort.sinkSmall (PkgSort omnetpp.vec)
Part Values in pkgSort.sinkMedium (PkgSort omnetpp.vec)
Figure 5.11: Package Sorter Entity values per sink.

The junction of Ports A and B can only allow one entity to pass at a time, if the
junction is in use then other entities are forced to wait, this is referred to as junction
delay. The effect of this delay was seen experimentally by increasing the number of
entities arriving at the Turnaround simultaneously.
The operation of the Crossover module was verified, in Experiment 3, by
showing experimentally that only the entities valued in the specified ranges were
crossed from one side to the other. Also, since the end-segments are stopped every
time an entity crosses over, the effect of this delay upon other entities was investigated.
The Inspection Station application was introduced and simulated. The initial
results were explained and shown to be correct. In Experiment 4 it was seen that
the simulator can be used for observing MAC related packet delays. Experiment 5
induced faults into system at varying rates, and the resulting delays in entity travel
times were reported.
The Package Sorting System was presented and used to show how the reconfigurability of the simulator can be used for practical purposes. The application
was simulated and it was shown that the layout directed Small, Medium and Large
66
Package Sorter Mean Entity Travel Times
18
16
14
20
30
40
50
Simulation Time (s)

Endtoend Part Travel Time in pkgSort.sinkLarge (PkgSort omnetpp.vec)
Endtoend Part Travel Time in pkgSort.sinkMedium (PkgSort omnetpp.vec)
Endtoend Part Travel Time in pkgSort.sinkSmall (PkgSort omnetpp.vec)
Figure 5.12: Package Sorter Mean end-to-end entity travel time.

entities to their correct destinations. In Experiment 6, a variation on the topology
was simulated too if it could decrease the travel times of Small entities.
The results from these experiments show that this simulator is a useful tool
for studying and reconfiguring conveyor systems that can be composed using the
Coupled Conveyors approach described in Chapter III.
67
CHAPTER VI
CONCLUSION
This thesis presented a compositional approach to building conveyor systems,

called Coupled Conveyors. Since this represented a significant departure from existing methods to engineer automation systems, it was necessary to establish that
the approach is valid. Thus a new simulator was designed to address this need.
Discrete Event Simulation is a robust framework for simulation and was
hence selected for this investigation. OMNeT++ was selected as a platform to
facilitate the development of the simulator.
The fundamental building blocks of Coupled Conveyors, namely Segment,
Turnaround and Crossover, were described in Chapter III. The behavior of these
blocks was precisely specified in a guarded command language, called UNITY. It
was shown that a variety of conveyor systems could be composed by embedding
these blocks in a two-dimensional grid.
Starting with the Coupled Conveyors method, software classes were designed
in C++ using an object-oriented methodology guided by the compositional approach from Chapter III. The Network Description language, provided by OMNeT++, was used to enable reconfiguration of the simulator. In Chapter IV and
V, three different examples of conveyor systems were presented.
The fidelity of the simulator was demonstrated, in detail, in Chapter V. After
establishing the validity of the building blocks, experiments were conducted to show
the effects of faults on the performance of the conveyor system. Further, the results
demonstrated that the simulator was useful in studying the communication and
68
the fault tolerance capabilities of the conveyor systems. The experiment with the
Package Sorting application showed that reconfigurability is beneficial to seasonally
improve throughput. These results are encouraging and motivate the development
of middleware and system software for networked embedded platforms.
In the future, this simulator can be extended in a number of directions: the
incorporation of highly detailed mechanical models, more accurate coupling between electrical and mechanical components of conveyor systems, Media Access
Control (MAC) protocols for the transceivers and methods for scheduling and the
synchronization of large-scale networked embedded systems.
69
BIBLIOGRAPHY
[1] J. Agre, L. Clare, and S. Sastry, A Taxonomy for Distributed Real-time Control
Systems, in Advances in Computers, M. Zelkowitz, Ed., vol. 49, pp. 303352.
Academic Press, 1999.
[2] Nunzio Hayslip, Shivakumar Sastry, and Jon S. Gerhardt, Networked embedded automation, Assembly Automation, vol. 26, no. 3, pp. 235241, 2006.
[3] Bernard P. Zeigler, Theory of Modelling and Simulation, Krieger Publishing
Co., Inc., 1984.
[4] David R. Jefferson, Virtual time, ACM Trans. Program. Lang. Syst., vol. 7,
no. 3, pp. 404425, 1985.
[5] K. Fall and K. Varadhan, The NS Manual (Formerly NS Notes and Documentation), 2002.
[6] K. Langendoen, A. Baggio, and O. Visser, Murphy loves potatoes: Experiences
from a pilot sensor network deployment in precision agriculture, in 14th
International Workshop on Parallel and Distributed Real-time Systems, Rhodes,
Greece, April 2006, 2006.
[7] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, System
Architecture Directions for Networked Sensors, ACM Sigplan Notices, vol. 35,
no. 11, pp. 93104, 2000.
[8] Philip Levis, Nelson Lee, Matt Welsh, and David Culler, TOSSIM: Accurate
and scalable simulation of entire TinyOS applications, in SenSys 03: Proceedings of the 1st international conference on Embedded networked sensor systems,
New York, NY, USA, 2003, pp. 126137, ACM Press.
[9] Gang Zhou, Tian He, Sudha Krishnamurthy, and John A. Stankovic, Impact
of radio irregularity on wireless sensor networks, in MobiSys 04: Proceedings
of the 2nd international conference on Mobile systems, applications, and services,
New York, NY, USA, 2004, pp. 125138, ACM Press.
[10] Victor Shnayder, Mark Hempstead, Bor rong Chen, Geoff Werner Allen, and
Matt Welsh, Simulating the power consumption of large-scale sensor network
applications, in SenSys 04: Proceedings of the 2nd international conference on
Embedded networked sensor systems, New York, NY, USA, 2004, pp. 188200,
ACM Press.
[11] J. Polley, D. Blazakis, J. McGee, D. Rusk, and J. S. Baras, ATEMU: a finegrained sensor network simulator, in Proceedings of First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, 2004.
70
[12] Ben L. Titzer, Daniel K. Lee, and Jens Palsberg, Avrora: scalable sensor network simulation with precise timing, in IPSN 05: Proceedings of the 4th international symposium on Information processing in sensor networks, Piscataway,
NJ, USA, 2005, p. 67, IEEE Press.
[13] S. Park, A. Savvides, and M. Srivastava, SensorSim: A simulation framework
for sensor networks, in Proc. of the ACM international Workshop on Modeling,
Analysis and Simulation of Wireless and Mobile Systems, 2000.
[14] Xiang Zeng, Rajive Bagrodia, and Mario Gerla, GloMoSim: a library for
parallel simulation of large-scale wireless networks, in PADS 98: Proceedings
of the twelfth workshop on Parallel and distributed simulation, Washington, DC,
USA, 1998, pp. 154161, IEEE Computer Society.
[15] R. Bagrodia, R. Meyer, M. Takai, Y. Chen, X. Zeng, J. Martin, B. Park, and
H. Song, Parsec: A parallel simulation environment for complex systems,
IEEE Computer, vol. 31, no. 10, pp. 7785, October 1998.
[16] Ahmed Sobeih, Wei P. Chen, Jennifer C. Hou, Lu C. Kung, Ning Li, Hyuk
Lim, Hung Y. Tyan, and Honghai Zhang, J-Sim: A simulation environment
for wireless sensor networks, in Annual Simulation Symposium, 2005, pp.
175187.
[17] Jean-Baptiste Filippi and Paul Bisgambiglia, JDEVS: an implementation of a
DEVS based formal framework for environmental modelling, Environmental
Modelling and Software, vol. 19, no. 3, pp. 261274, 2004.
[18] Costas Simatos, Making simJava count, M.Sc. Project Report, University of
Edinburgh, School of Informatics, September 2002.
[19] Philip Baldwin, Sanjeev Kohli, Edward A. Lee, Xiaojun Liu, and Yang Zhao,
Visualsense: Visual modeling for wireless and sensor network systems, Tech.
Rep. 25, EECS Dept., UC Berkeley, July 2005.
[20] Xiaojun Liu, Yuhong Xiong, and Edward A. Lee, The Ptolemy II framework
for visual languages, in HCC 01: Proceedings of the IEEE 2001 Symposia on
Human Centric Computing Languages and Environments (HCC01), Washington, DC, USA, 2001, p. 50, IEEE Computer Society.
[21] Judy Rathmell and David T. Sturrock, Arena: the arena product family: enterprise modeling solutions, in WSC 02: Proceedings of the 34th conference
on Winter simulation. 2002, pp. 165172, Winter Simulation Conference.
[22] Xinjie Chang, Network simulations with OPNET, in WSC 99: Proceedings
of the 31st conference on Winter simulation, New York, NY, USA, 1999, pp.
307314, ACM Press.
Projects that use OMNeT++,
[23] Andras Varga,
http://www.omnetpp.org/index.php?topic=Projects.
October 2006,
[24] INET framework for OMNEST/OMNeT++: A guided tour, September 2006,

http://www.omnetpp.org/doc/INET/walkthrough/tutorial.html.
71
[25] Mobility Framework

fw.sourceforge.net/.
for
OMNet++,
2006,
http://mobility-
[26] Stefan Dulman, Omer Sinan Kaya, and Georgi Koprinkov, EYES WSN Simulation Framework, September 2005, http://wwwes.cs.utwente.nl/ewsnsim/.
[27] Andras Varga, OMNeT++ User Manual, 2006.
[28] H.P. Bloch and C. Soares, Process Plant Machinery, Butterworth-Heinemann,
1998.
[29] K. M. Chandy and J. Misra, Parallel Program Design: A Foundation, Addison
Wesley, 1988.
[30] L. Bass, P. Clements, and R. Kazman,
Addison-Wesley, 1998.
Software Architecture in Practice,
[31] Jason Hill, Mike Horton, Ralph Kling, and Lakshman Krishnamurthy, The
platforms enabling wireless sensor networks, Commun. ACM, vol. 47, no. 6,
pp. 4146, 2004.
72

A Reconfigurable Simulator For Coupled Conveyors

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

A Reconfigurable Simulator For Coupled Conveyors

Diunggah oleh

Hak Cipta:

Format Tersedia

A RECONFIGURABLE SIMULATOR FOR COUPLED CONVEYORS

A RECONFIGURABLE SIMULATOR FOR COUPLED CONVEYORS

Dean of the College

Dean of the Graduate School

1.2 Research Approach . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 Overview of Thesis . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Discrete Event Simulation . . . . . . . . . . . . . . . . . . . . . .

2.2 Network Simulators . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1 Commercial Simulators . . . . . . . . . . . . . . . . . . .

3.1 Building Blocks of Coupled Conveyors . . . . . . . . . . . . . . .

3.2 Composing Systems From Blocks . . . . . . . . . . . . . . . . . .

3.2.1 Embedding CCS in a Grid . . . . . . . . . . . . . . . . . .

3.3 Behavior of NEA Nodes . . . . . . . . . . . . . . . . . . . . . . .

3.3.1 Specification for Segment . . . . . . . . . . . . . . . . . .

3.3.2 Specification for Turnaround . . . . . . . . . . . . . . . .

3.3.3 Specification for Crossover . . . . . . . . . . . . . . . . .

3.4 Benefits of Coupled Conveyors . . . . . . . . . . . . . . . . . . .

SIMULATOR DESIGN AND IMPLEMENTATION . . . . . . . . . . . . . .

4.2 Entity Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Entity Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Building Blocks for Coupled Conveyors . . . . . . . . . . . . . .

4.6 Monitoring Station . . . . . . . . . . . . . . . . . . . . . . . . .

4.7 Building an Application . . . . . . . . . . . . . . . . . . . . . . .

APPLICATIONS AND RESULTS . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Basic Simulation Setup . . . . . . . . . . . . . . . . . . . . . . .

5.2 Behavior of Building Blocks . . . . . . . . . . . . . . . . . . . . .

5.2.1 Baseline Experiment

5.2.2 Experiment 1 - Segment Behavior . . . . . . . . . . . . .

5.2.3 Experiment 2 - Turnaround Behavior . . . . . . . . . . .

5.2.4 Experiment 3 - Crossover Behavior

5.3 Inspection Station . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . .

5.3.2 Simulation Results

5.3.3 Experiment 4 - Communication . . . . . . . . . . . . . .

5.3.4 Experiment 5 - Fault Tolerance . . . . . . . . . . . . . . .

5.4 Package Sorting System . . . . . . . . . . . . . . . . . . . . . . .

5.4.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . .

5.4.2 Simulation Results

5.4.3 Experiment 6 - Topology Changes . . . . . . . . . . . . .

3.1 Notation for Specifications . . . . . . . . . . . . . . . . . . . . . . . .

5.1 Parameters Values . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Baseline Experiment Parameters . . . . . . . . . . . . . . . . . . . . .

5.3 Parameters for Validating Segment . . . . . . . . . . . . . . . . . . .

5.4 Validating the Segment Simulation Results . . . . . . . . . . . . . .

5.5 Effects of Changing Speed and Entity Length . . . . . . . . . . . . . .

5.6 Parameters for Validating the Turnaround . . . . . . . . . . . . . . .

5.7 Overall Simulation Results . . . . . . . . . . . . . . . . . . . . . . . .

5.8 Average End-to-end Travel Time Per Sink . . . . . . . . . . . . . . . .

5.9 Turnaround with Varying Deflect Ranges . . . . . . . . . . . . . . . .

5.10 Parameters for Validating the Crossover . . . . . . . . . . . . . . . .

5.11 Overall Simulation Results . . . . . . . . . . . . . . . . . . . . . . . .

5.12 Validating the Crossover - Entity Latency . . . . . . . . . . . . . . . .

5.13 Inspection Station Parameters . . . . . . . . . . . . . . . . . . . . . .

5.14 Inspection Station Simulation Results . . . . . . . . . . . . . . . . . .

5.15 Inspection Station Experiment 4 Results . . . . . . . . . . . . . . . .

5.16 Inspection Station Experiment 5 Results . . . . . . . . . . . . . . . .

5.17 Package Sorting Simulation Parameters . . . . . . . . . . . . . . . . .

5.18 Package Sorter Simulation Results . . . . . . . . . . . . . . . . . . . .

5.19 Reconfigured Package Sorter Results . . . . . . . . . . . . . . . . . .

1.1 Traditional Automation System . . . . . . . . . . . . . . . . . . . . .

1.2 Emergence of Networked Embedded Systems . . . . . . . . . . . . .

1.3 Wireless Communicaiton in Automation . . . . . . . . . . . . . . . .

3.1 Coupled Conveyors Building Blocks . . . . . . . . . . . . . . . . . . .