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 Department ChairDr. Shivakumar Sastry Dr. Alex De Abreu Garcia

Committee Member Dean of the CollegeDr. Nathan Ida Dr. George K. Haritos

Committee Member Dean of the Graduate SchoolDr. James E. Grover 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 oper-

ations. 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 behav-

ior of Segment, Turnaround, and Crossover. These modules were used to com-

pose 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 moment’s 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, I’d 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. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

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

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

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

II. BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

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

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

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

2.3 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

III. 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

v

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

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

IV. 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

V. APPLICATIONS AND RESULTS . . . . . . . . . . . . . . . . . . . . . . . . 42

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

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

5.2.1 Baseline Experiment . . . . . . . . . . . . . . . . . . . . 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

5.4.2 Simulation Results . . . . . . . . . . . . . . . . . . . . . 63

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

5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

VI. CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vi

BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

vii

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 . . . . . . . . . . . . . . . . . . . . . 2

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

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

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

x

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 spec-

trum 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, reconfig-

urable 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 non-

deterministic 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 sys-

tems with reconfigurable topologies. Networked embedded systems may be appro-

1

Automation System

Input

Output Logic Processing

Control Behavior

Specification

HCI

Supervisory Controller

PB Panel 1

Programming

Tool 1

tttt

Controller1

Zone 1

Programming

Tool 3

Sensors &

Actuators 1

tttt

Controller3

PB Panel 3Sensors &

Actuators 3

Zone 3

Sensors &

Actuators 2

Zone 2

tttt

Controller2Programming

Tool 2

PB Panel 2

Figure 1.1: Traditional Automation System

priate for this task. Figure 1.2 depicts the emergence of networked embedded sys-

tems 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 re-

configurable systems using three building blocks that are called Segment, Turnaround,

and Crossover. A local microcontroller, which was integrated with a low-power ra-

dio transceiver, is associated with each building block. These microcontrollers com-

prised 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.

2

Networked

Embedded

Systems

Sensor Networks

Safety

Predictability

Reliability

Maintainability

Inherent Distribution

Performance

Incremental Growth

Economics

Distributed

Computing

Mobile

Computing

Automation

Systems

Resource Limited

Energy ConservingMobile Devices

Wireless

Energy Awareness

Location Awareness

Networked

Embedded

Systems

Sensor NetworksSensor Networks

Safety

Predictability

Reliability

Maintainability

Inherent Distribution

Performance

Incremental Growth

Economics

Distributed

Computing

Mobile

Computing

Mobile

Computing

Automation

Systems

Automation

Systems

Resource Limited

Energy ConservingMobile Devices

Wireless

Energy Awareness

Location Awareness

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 sim-

ulate and study the performance of a variety of conveyor systems. In addition, it

was necessary to validate the compositional approach advocated for Coupled Con-

veyors 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 sim-

ulation 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 net-

worked embedded system that regulates its operation.

3

Specific

Behavior

Module

Automation System

Input

Logic Processing HMIOutput

Monitoring

Wired

Retargetable

Push Button Panel 1

Wireless

Retargetable

Push Button Panel 2

Communication Media

(Wireless with wired

segments)

Retargetable

Programming

Devices

Specific

Behavior

Module

Automation System

Input

Logic Processing HMIOutput

Monitoring Specific

Behavior

Module

Automation System

Input

Logic Processing HMIOutput

Monitoring

Automation System

Input

Logic Processing HMIOutput

Monitoring

Wired

Retargetable

Push Button Panel 1

Wireless

Retargetable

Push Button Panel 2

Communication Media

(Wireless with wired

segments)

Retargetable

Programming

Devices

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 OM-

NeT++ 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.

4

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 simula-

tor 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, Cou-

pled Conveyors is defined in detail with an example to illustrate how Segment,

Turnaround, and Crossover are used to compose conveyor systems. The object-

oriented design of the simulator is presented in Chapter IV. The Network De-

scription 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.

5

CHAPTER II

BACKGROUND

This chapter briefly describes discrete event simulation and surveys the lit-

erature 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 be-

tween 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 envi-

ronment. 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 main-

tain a queue of events that must be processed in the time-order they were gener-

ated. 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 Sim-

ulator 2 (NS-2) is dominant and has been used in academic research. Such a sim-

ulator 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 config-

uration 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 use-

ful 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 applica-

tions [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 event-

triggered paradigm supported under TinyOS. While this paradigm is useful for low-

demand 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-

7

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, fo-

cused 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. Het-

erogeneous networks, those with multiple hardware platforms, are also supported,

though this support is limited to AVR processor based systems. A graphical debug-

ger, 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

8

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 tim-

ing/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 synchro-

nizes 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. Sen-

sorSim’s 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 simu-

lates 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-

9

ulations across, up to, 16 processors.

J-Sim [16] was built on top of SensorSim but uses its own component ar-

chitecture and internetworking framework. It does share a number of SensorSim’s

features, including the power consumption modeling and support for hybrid simula-

tion. 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 Perime-

ter 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-Sim’s 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 environ-

mental 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 visual-

ization 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. SimJava’s 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 component-

based construction of network models and an “actor oriented” definition of nodes,

channels, physical media and subsystems. Custom components are created by sub-

classing 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 manu-

facturing 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]. OM-

Net++ 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 fea-

tures.

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 num-

ber 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 cer-

tain modules to the inputs of other modules.

11

OMNet++ supports simple and compound modules. For each simple mod-

ule, 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 cMes-

sage 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 be-

tween 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 com-

pound 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 cre-

ate executables for Windows, Linux or other platforms without the overhead of a

Virtual Machine (a la 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, subsys-

tems 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 micro-

controllers regulate automation applications, as Networked Embedded Automation

(NEA) [2].

The sensors and actuators on every building block are connected to a resource-

constrained 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 val-

ues 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

u dau da

(a) Segment

uAuB dC

dDa

pdPort A

Port B Port C

Port D

ps

uAuB dC

dDa

pdPort A

Port B Port C

Port D

ps

(b) Turnaround

e1 e2

a

Segment 1 Segment 2

e1 e2

a

Segment 1 Segment 2

(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 con-

veyor systems are obtained by simply placing the building blocks in appropriate

positions. There is no need for programming or configuring the “system”. By in-

corporating monitoring stations and operator interaction panels to support human-

computer 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 be-

havior. 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 prox-

imity 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

1One 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 exam-

ple, 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 exam-

ple, 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 in-

stance 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 ap-

propriate 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

2In addition to the sensors and actuators on the modules such an application would use additionaldevices such as cameras, RFID tags and scanners, weighing scales, etc. to inspect the entities thatare being moved.

19

North

0,0

0,1

0,2

0,3

0,4

6,0

0,5

T1

S12

S13 S14 S17T4

T2

T3

C1

1,0 2,0 3,0 4,0 5,0

S15

S18

S11

S1 S2 S3 S4 S5

S6

S7S8S9S10

S16Manual

Inspection

H2

H1 H3

T1

S12

S13 S14 S17T4

T2

T3

C1

1,0 2,0 3,0 4,0 5,0

S15

S18

S11

S1 S2 S3 S4 S5

S6

S7S8S9S10

S16Manual

Inspection

H2

H1 H3

Figure 3.2: An Example Conveyor System

20

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 CCSare 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.3Note that these specifications only cover the automatic mode of operation.

21

Symbol Meanings ↑ Sensor s is actives ↓ Sensor s is inactive

s ↗ Sensor s made a transition from inactive to actives ↘ Sensor s made a transition from active to inactive

a Actuator a is energizeda Actuator a is de-energized

⇀ a Actuator a is being energized⇁ a 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 down-

stream 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, mWDT , with a preset time (mWDT.preset). As shown in actions S3 and

S4, if an entity arrives on the Segment before mWDT expires, then the watchdog

timer is reset and si.a continues to remain energized. If, however, mWDT 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 (mWDT ) to regulate the flow of

entities from either input port as shown in action T5. The boolean variable acceptin-

gEntity 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 en-

tity 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 connec-

tivity 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 topolo-

gies for systems.

For example, in the material inspection application shown in Figure 3.2, sup-

pose 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 configura-

tion involved when the topology changes in this manner because the interactions

between blocks are designed to accommodate such changes.

24

BuildingBlock Segmentvar

beltFull: BooleannumEntities: Integer

initiallybeltFull ≡ (numEntities = lenm/lene)

assignS1: d ↗ −→

OutChanneld := Req-Actuator-On[]S2: InChannelu = Req-Actuator-On ∧ ¬beltFull −→

⇀ a ;mWDT.Start

[]S3: mWDT.done ∧ u ↓ ∧ a −→

⇁ a[]S4: mWDT.tt ∧ u ↗ −→

mWDT.StopnumEntities := 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 Turnaroundvar

beltFull: BooleanacceptingEntity: BooleandeflectEntity: BooleannumEntities: Integer

initiallybeltFull ≡ (numEntities = lenm/lene)

assignT1: dC ↗ −→

OutChannelC := Req-Actuator-On;[]T2: dD ↗ −→

OutChannelD := Req-Actuator-On;[]T3: InChannelA = Req-Actuator-On ∧ ¬beltFull ∧ ¬acceptingEntity −→

⇀ a;acceptingEntity := true;mWDT.Start;

[]T4: InChannelB = Req-Actuator-On ∧ ¬beltFull ∧ ¬acceptingEntity −→

⇀ a;acceptingEntity := true;mWDT.Start;

[]T5: mWDT.done ∧ uA ↓ ∧ uB ↓ ∧ a −→

⇁ a;mWDT.Stop;

[]T6: mWDT.tt ∧ uA ↗ ∧ a −→

mWDT.Stop;numEntities := numEntities + 1

[]T7: uA ↘−→

acceptingEntity := false;OutChannelA := Actuator-Off;

[]T8: mWDT.tt ∧ uB ↗ ∧ a −→

mWDT.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: deflectEntity∧ ps↗ −→

⇀ pd;[]T15: numEntities = 0 ∧ a −→

⇁ a;[]end Turnaround

Figure 3.5: Specification for Turnaround - Continued

27

BuildingBlock Crossover cassignC1: e1↗ ∧ a12 ∧ a21 −→

OutChannels1 := ForceStop;OutChannels2 := ForceStop

[]C2: e2↗ ∧ ˙a21 ∧ a12 −→

OutChannels1 := ForceStop;OutChannels2 := ForceStop

[]C3: e2↑ ∧ a12 −→

⇁ ˙a12 ;OutChannels1 := ReleaseStop;OutChannels2 := ReleaseStop

[]C4: e1↑ ∧ a21−→

⇁ ˙a21 ;OutChannels1 := ReleaseStop;OutChannels2 := ReleaseStop

[]C5: InChannels1 = Stopped ∧

InChannels2 = Stopped ∧ e1↑ −→⇀ a12

[]C6: InChannels1 = Stopped ∧

InChannels2 = Stopped ∧ e2↑ −→⇀ a21

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 cap-

ture 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 con-

veyor 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 config-

urable 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 enti-

ties are generated. Speed specifies the speed with which an entity leaves the Enti-

tySource. In the simulator, this phenomenon is represented as two messages — the

first being EntityBegin and the second being EntityEnd. The Speed parameters deter-

mines the time interval between these two messages. The entityLength parameter

refers to the length of all the entities generated by the EntitySource, and entitiesTo-

Generate 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 pa-

rameterized 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 conve-

nient 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

1There 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.

2OMNet++ 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 sub-

modules. The NEANode represents the microcontroller with its integrated transceiver

and the software that executes on an NEA node.

Segment

Node

Microprocessor

Metal

Lip

DownstreamSensor

SensorAdaptor

Lip

UpstreamSensor

MotorActuatorAdaptor

Interactor

Transceiver

LocalActor Coordinator

Communications Medium

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 Sen-

sorAdaptor, 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 Enti-

tyEnd 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 Ac-

tuatorAdaptor 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 OM-

NeT++ 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 con-

veyor 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 SegmentInterac-

tor, 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, Micro-

controller 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 mod-

ules. 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 Co-

ordinator. 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 imple-

mented 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 nor-

mally take to send the packet based on the transceiver’s 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 · numberOfAttempts + uniform(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 node’s 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 parame-

ters. 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 ar-

rays, 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];

gatesizes: entitiesIn[2], entitiesOut[2];

cccrossovers : CCCrossover[numCrossovers];

gatesizes: entitiesIn[2], entitiesOut[2];

source : Source;

sink : Sink;

endmodule

Now, add a connections section to the SCS module. Connect the Coupled Con-

veyors 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 pa-

rameters and simulation settings need to be defined in the ‘omnetpp.ini’ file. OM-

NeT++ 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 applica-

tions of Coupled Conveyors, are discussed in the next chapter.

0,0

0,1

1,0 4,0

S0 S1 S4

Test

Factory

Src

SrcBSinkB

Sink

S3S2

C0

H1

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 Con-

veyor 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 Inspec-

tion 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, tradi-

tional 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 ValueEntity Length 1.0 unitBelt/Motor Speed 5.0 units/secLip Length 5.0e-2 unitsSegment Length 10.0 unitsTurnaround Length 10.0 unitsTurnaround Leg Length 1.0 unitsTurnaround Leg Width 1.0 unitsCrossover Length 12.0 unitsCrossover Arm Offset 6.0 unitsCrossover Arm Travel Distance 5.0 unitsCrossover Arm Speed 5.0 units/secTransceiver Data Rate 2.4 kbytes/secMonitoring Station Polling Interval 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 Crossbow’s 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 ValueSimulation Time 100.0sSrcInterval 1.0Value intuniform(1, 15)SrcB

Interval 2.2Value intuniform(6, 20)Turnaround Deflect Range 11. . . 20Crossover AD to BC Range 15. . . 20Crossover BC to AD Range 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.

E n d − t o − e n d P a r t T r a v e l T i m e i n f a c t o r y . s i n k ( o m n e t p p C r o s s o v e r 1 2 . v e c )

E n d − t o − e n d P a r t T r a v e l T i m e i n f a c t o r y . s i n k B ( o m n e t p p C r o s s o v e r 1 2 . v e c )

TestFac to ry End−to−end Par t T rave l T ime

Par t S i nk T ime ( s )

2 0 4 0 6 0 8 0

Pa

rt T

rav

el

Tim

e (

s)

0

5

1 0

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 station’s polling, which is set to every 5.0 seconds; because

45

P a r t V a l u e s i n f a c t o r y . s i n k ( o m n e t p p . v e c ) P a r t V a l u e s i n f a c t o r y . s i n k B ( o m n e t p p . v e c )

Test Factory −− Ent i ty Values

S imu l t a t i on T ime ( s )

2 0 4 0 6 0 8 0

En

tity

Va

lue

5

1 0

1 5

2 0

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

Tes t Fac to ry −− Packe t T ransmiss ion T imes

T i m e ( s )

2 0 4 0 6 0 8 0

Pa

ck

et

Tra

ns

mis

sio

n D

ura

tio

n (

s)

0 . 0 5

0 . 1

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 ValueSimulation Time 150.0sSrcEntities To Generate 100Interval 1.0Value intuniform(1, 15)Turnaround Deflect Range 0. . . 0Crossover AD to BC Range 0. . . 0Crossover BC to AD Range 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 enti-

ties 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 ValueSrc Entities Generated 100SrcB Entities Generated 0Sink Entities Consumed 100SinkB Entities Consumed 0Entity Travel Time 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) Entity Length (units) Entity Travel Time (s)5.0 1.0 8.285.0 2.0 8.485.0 6.0 9.285.0 20.0 12.0810.0 1.0 4.1410.0 2.0 4.2410.0 6.0 4.6410.0 20.0 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.4units5.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. Con-

48

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. Conse-

quently, 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 exclu-

sion 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 ValueSimulation Time 250.0sSrcEntities To Generate 100Interval 1.0Value intuniform(1, 15)SrcB

Entities To Generate 100Interval 2.2Value intuniform(6, 20)Turnaround Deflect Range 11. . . 20Crossover AD to BC Range 0. . . 0Crossover BC to AD Range 0. . . 0

Table 5.6: Parameters for Validating the Turnaround

Property ValueSrc Entities Generated 100SrcB Entities Generated 100Sink Entities Consumed 91SinkB Entities Consumed 109T0 Entities Deflected 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. Fig-

ure 5.6 shows that the end-to-end travel times of a larger number of entities in-

crease. 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 Avg. Travel Time (Sink) Avg. Travel Time (SinkB)3.0 10.88 8.371.37 10.94 8.398.9e-1 10.99 8.457.2e-1 11.02 8.46

Table 5.8: Average End-to-end Travel Time Per Sink

50

P a r t V a l u e s i n f a c t o r y . s i n k ( V T 1 o m n e t p p . v e c ) P a r t V a l u e s i n f a c t o r y . s i n k B ( V T 1 o m n e t p p . v e c )

Va l ida t i ng the Tu rna round : En t i t y Va lues Per S ink T ime

S imu la t i on T ime ( s )

1 0 0 2 0 0

En

tity

Va

lue

5

1 0

1 5

2 0

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 sec-

ond 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. En-

tities with values in the range [1, 5] are exclusive to Src since SrcB only generates

entities with values in the range [6, 20].

Turnaround Deflect Range Sink Entities Consumed SinkB Entities Consumed15. . . 20 150 501. . . 10 98 10211. . . 20 91 1091. . . 20 0 2000. . . 0 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 ar-

51

E n d − t o − e n d P a r t T r a v e l T i m e i n f a c t o r y . s i n k ( V T 1 o m n e t p p . v e c )

E n d − t o − e n d P a r t T r a v e l T i m e i n f a c t o r y . s i n k B ( V T 1 o m n e t p p . v e c )

Val ida t ing the Turnaround : En t i t y T rave l T imes

S imu la t i on T ime ( s )

1 0 0 2 0 0

En

tity

Tra

ve

l D

ura

tio

n (

s)

9

1 0

1 1

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 ac-

tually 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

E n d − t o − e n d P a r t T r a v e l T i m e i n f a c t o r y . s i n k ( o m n e t p p . v e c )

E n d − t o − e n d P a r t T r a v e l T i m e i n f a c t o r y . s i n k B ( o m n e t p p . v e c )

Va l ida t i ng the Tu rna round : I nc reased Por t A /B de lays

S imu la t i on T ime ( s )

5 0 1 0 0

En

tity

Tra

ve

l D

ura

tio

n (

s)

9

1 0

1 1

Figure 5.6: Effects of Mutual Exclusion

Parameter ValueSimulation Time 450.0sSrcB

Entities To Generate 100Interval 4.0Value intuniform(1, 20)Turnaround Deflect Range 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 Crossover’s 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

Crossover’s end-segments at the same time, and hence, none are delayed.

Crossover AD to BC Range Sink Entities SinkB Entities Path 3 Path 40. . . 0 (0%) 100 0 8.68s -1. . . 20 (100%) 0 100 - 3.62s1. . . 5 (25%) 75 25 8.68s 3.62s1. . . 10 (50%) 48 52 8.68s 3.62s1. . . 15 (75%) 26 74 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

North

0,0

0,1

0,2

0,3

0,4

6,0

0,5

T1

S12

S13 S14 S17T4

T2

T3

C1

1,0 2,0 3,0 4,0 5,0

S15

S18

S11

S1 S2 S3 S4 S5

S6

S7S8S9S10

S16Manual

Inspection

H2

H1 H3

T1

S12

S13 S14 S17T4

T2

T3

C1

1,0 2,0 3,0 4,0 5,0

S15

S18

S11

S1 S2 S3 S4 S5

S6

S7S8S9S10

S16Manual

Inspection

H2

H1 H3

Figure 5.7: An Inspection System

55

SrcB Interval Crossover AD to BC Range Path 3 Path 41.0s 0. . . 0 8.68 -1.0s 1. . . 5 8.72 3.651.0s 1. . . 10 8.96 3.831.0s 1. . . 15 9.18 4.101.0s 1. . . 20 - 4.621.5s 0. . . 0 8.68 -1.5s 1. . . 5 8.78 3.841.5s 1. . . 10 9.00 3.911.5s 1. . . 15 9.01 4.021.5s 1. . . 20 - 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.1In 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 theentities that are being moved.

56

5.3.1 Simulation Setup

For simulation purposes, EntitySources were placed at S6 and S17 and Enti-

tySinks were placed at S1 and S18. To simulate the manual inspection of entities, a

long slow segment, S0, is placed between S15 and S12 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 S11.

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 random-

ization 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 de-

scribed 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.

5.3.2 Simulation Results

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 ValueSimulation Time 110.0sMonitoring Message Request Every 5 secondsFor source6:Entities To Generate 50Interval 1.0Value intuniform(1, 15)For source17:Entities To Generate 25Interval 3.5Value intuniform(6, 20)T1 Deflect Range intuniform(0, 2)T2 Deflect Range 1. . . 10T3 Deflect Range 11. . . 20T4 Deflect Range 1. . . 10C0 BC to AD Range intuniform(0, 2)

Table 5.13: Inspection Station Parameters

Property Valuesink1 Entities Consumed 42sink18 Entities Consumed 33T1 Entities Deflected 5 out of 47 (10.63%)T2 Entities Deflected 47 out of 62 (75.81%)T3 Entities Deflected 33 out of 40 (82.50%)T4 Entities Deflected 7 out of 40 (17.50%)C0 Entities Crossed BC to AD 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 de-

flected, 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 re-

sults 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 communica-

tions in a realistic application of Coupled Conveyors.

Modeling the network communication between NEA Nodes is a crucial as-

59

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, communi-

cate 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 Modules per Medium Mean Packet Latency (s)One 24 1.01e-1Two 14.5 9.3e-2Four 8.5 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 Inspec-

tion 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 ex-

pected, 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 evalu-

ate 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 ex-

ample, 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 prob-

abilities, 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 Mean Entity Travel Time (s)0% 19.810.1% 20.500.5% 20.660.6% 21.441% 22.552% 23.505% 23.7320% 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 destina-

tions.

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 ValueSimulation Time 100.0sFor sourceI1 . . . sourceI5 :Parts To Generate 30Interval 1.0Value intuniform(1, 30)T1 Deflect Range 11. . . 30T2 Deflect Range 21. . . 30T3 Deflect Range 1. . . 10T4 Deflect Range 11. . . 30T5 Deflect Range n/aT6 Deflect Range 1. . . 20T7 Deflect Range 11. . . 20T8 Deflect Range 21. . . 30C0 AD to BC Range 11. . . 30C0 BC to AD Range 1. . . 10

Table 5.17: Package Sorting Simulation Parameters

5.4.2 Simulation Results

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 con-

firms that the topology and the configuration correctly directed Small, Medium, and

Large entities to sinkSmall, sinkMedium, 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 ValuesinkSmall Entities Arrived 44sinkMedium Entities Arrived 54sinkLarge Entities Arrived 52T1 Deflected 21 out of 45T2 Deflected 31 out of 66T3 Deflected 20 out of 74T4 Deflected 0 out of 44T5 Deflected 0 out of 60T6 Deflected 39 out of 91T7 Deflected 54 out of 54T8 Deflected 52 out of 52C0 Crossed AD to BC 21 out of 60C0 Crossed BC to AD 7 out of 60Small Travel Time 16.52sMedium Travel Time 18.31sLarge Travel Time 18.94s

Table 5.18: Package Sorter Simulation Results

Property ValueSmall Travel Time 16.27sMedium Travel Time 17.93sLarge Travel Time 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 behav-

ior 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 re-

sults. 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

P a r t V a l u e s i n p k g S o r t . s i n k L a r g e ( P k g S o r t o m n e t p p . v e c )

P a r t V a l u e s i n p k g S o r t . s i n k M e d i u m ( P k g S o r t o m n e t p p . v e c )

P a r t V a l u e s i n p k g S o r t . s i n k S m a l l ( P k g S o r t o m n e t p p . v e c )

Package Sor te r −− En t i t y Va lues a t each S ink

S imu la t i on T ime ( s )

2 0 3 0 4 0 5 0

En

tity

Va

lue

1 0

2 0

3 0

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 investi-

gated.

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 re-

configurability 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

E n d − t o − e n d P a r t T r a v e l T i m e i n p k g S o r t . s i n k L a r g e ( P k g S o r t o m n e t p p . v e c )

E n d − t o − e n d P a r t T r a v e l T i m e i n p k g S o r t . s i n k M e d i u m ( P k g S o r t o m n e t p p . v e c )

E n d − t o − e n d P a r t T r a v e l T i m e i n p k g S o r t . s i n k S m a l l ( P k g S o r t o m n e t p p . v e c )

Package Sor te r −− Mean En t i t y T rave l T imes

S imu la t i on T ime ( s )

2 0 3 0 4 0 5 0

En

tity

Tra

ve

l D

ura

tio

n (

s)

1 4

1 6

1 8

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 ex-

isting 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 ap-

proach from Chapter III. The Network Description language, provided by OM-

NeT++, 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 be-

tween 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 ControlSystems,” in Advances in Computers, M. Zelkowitz, Ed., vol. 49, pp. 303–352.Academic Press, 1999.

[2] Nunzio Hayslip, Shivakumar Sastry, and Jon S. Gerhardt, “Networked embed-ded automation,” Assembly Automation, vol. 26, no. 3, pp. 235–241, 2006.

[3] Bernard P. Zeigler, Theory of Modelling and Simulation, Krieger PublishingCo., Inc., 1984.

[4] David R. Jefferson, “Virtual time,” ACM Trans. Program. Lang. Syst., vol. 7,no. 3, pp. 404–425, 1985.

[5] K. Fall and K. Varadhan, “The NS Manual (Formerly NS Notes and Documen-tation),” 2002.

[6] K. Langendoen, A. Baggio, and O. Visser, “Murphy loves potatoes: Experiencesfrom 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, “SystemArchitecture Directions for Networked Sensors,” ACM Sigplan Notices, vol. 35,no. 11, pp. 93–104, 2000.

[8] Philip Levis, Nelson Lee, Matt Welsh, and David Culler, “TOSSIM: Accurateand scalable simulation of entire TinyOS applications,” in SenSys ’03: Proceed-ings of the 1st international conference on Embedded networked sensor systems,New York, NY, USA, 2003, pp. 126–137, ACM Press.

[9] Gang Zhou, Tian He, Sudha Krishnamurthy, and John A. Stankovic, “Impactof radio irregularity on wireless sensor networks,” in MobiSys ’04: Proceedingsof the 2nd international conference on Mobile systems, applications, and services,New York, NY, USA, 2004, pp. 125–138, ACM Press.

[10] Victor Shnayder, Mark Hempstead, Bor rong Chen, Geoff Werner Allen, andMatt Welsh, “Simulating the power consumption of large-scale sensor networkapplications,” in SenSys ’04: Proceedings of the 2nd international conference onEmbedded networked sensor systems, New York, NY, USA, 2004, pp. 188–200,ACM Press.

[11] J. Polley, D. Blazakis, J. McGee, D. Rusk, and J. S. Baras, “ATEMU: a fine-grained sensor network simulator,” in Proceedings of First Annual IEEE Com-munications Society Conference on Sensor and Ad Hoc Communications and Net-works, 2004.

70

[12] Ben L. Titzer, Daniel K. Lee, and Jens Palsberg, “Avrora: scalable sensor net-work simulation with precise timing,” in IPSN ’05: Proceedings of the 4th inter-national 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 frameworkfor 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 forparallel simulation of large-scale wireless networks,” in PADS ’98: Proceedingsof the twelfth workshop on Parallel and distributed simulation, Washington, DC,USA, 1998, pp. 154–161, IEEE Computer Society.

[15] R. Bagrodia, R. Meyer, M. Takai, Y. Chen, X. Zeng, J. Martin, B. Park, andH. Song, “Parsec: A parallel simulation environment for complex systems,”IEEE Computer, vol. 31, no. 10, pp. 77–85, October 1998.

[16] Ahmed Sobeih, Wei P. Chen, Jennifer C. Hou, Lu C. Kung, Ning Li, HyukLim, Hung Y. Tyan, and Honghai Zhang, “J-Sim: A simulation environmentfor wireless sensor networks,” in Annual Simulation Symposium, 2005, pp.175–187.

[17] Jean-Baptiste Filippi and Paul Bisgambiglia, “JDEVS: an implementation of aDEVS based formal framework for environmental modelling,” EnvironmentalModelling and Software, vol. 19, no. 3, pp. 261–274, 2004.

[18] Costas Simatos, “Making simJava count,” M.Sc. Project Report, University ofEdinburgh, 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 frameworkfor visual languages,” in HCC ’01: Proceedings of the IEEE 2001 Symposia onHuman Centric Computing Languages and Environments (HCC’01), Washing-ton, DC, USA, 2001, p. 50, IEEE Computer Society.

[21] Judy Rathmell and David T. Sturrock, “Arena: the arena product family: en-terprise modeling solutions,” in WSC ’02: Proceedings of the 34th conferenceon Winter simulation. 2002, pp. 165–172, Winter Simulation Conference.

[22] Xinjie Chang, “Network simulations with OPNET,” in WSC ’99: Proceedingsof the 31st conference on Winter simulation, New York, NY, USA, 1999, pp.307–314, ACM Press.

[23] Andras Varga, “Projects that use OMNeT++,” October 2006,http://www.omnetpp.org/index.php?topic=Projects.

[24] “INET framework for OMNEST/OMNeT++: A guided tour,” September 2006,http://www.omnetpp.org/doc/INET/walkthrough/tutorial.html.

71

[25] “Mobility Framework for OMNet++,” 2006, http://mobility-fw.sourceforge.net/.

[26] Stefan Dulman, Omer Sinan Kaya, and Georgi Koprinkov, “EYES WSN Simula-tion 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, AddisonWesley, 1988.

[30] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice,Addison-Wesley, 1998.

[31] Jason Hill, Mike Horton, Ralph Kling, and Lakshman Krishnamurthy, “Theplatforms enabling wireless sensor networks,” Commun. ACM, vol. 47, no. 6,pp. 41–46, 2004.

72