MODELING HEALTHCARE LOGISTICS IN A VIRTUAL WORLD:
THE DATABASE CONNECTION
MODELING HEALTHCARE LOGISTICS IN A VIRTUAL WORLD:
THE DATABASE CONNECTION
A thesis submitted in partial fulfillment
of the requirements for the degree of
Master of Science in Computer Science
By
Ala’a Y. Ahmad
Alzaytoonah University
Bachelor of Science in Computer Science, 2004
May 2009
University of Arkansas
ABSTRACT
The “Everything is Alive” research project at the University of Arkansas is
focused on pervasive computing. In recent years, the project has explored agent systems,
RFID middleware, and is now studying how 3D virtual world technology can be used as
a platform to model a future real world where computing is pervasive. The virtual world
project is modeling a hospital. A hospital is a good application target for this research
because the project can explore research questions about a coming “smart world” where
devices and people communicate, using an environment where low cost simulations in a
high value domain could provide improved safety or lowered cost.
This thesis explores a subproblem – can we connect a database management
system to a virtual world as a recording device for recording everything in the virtual
world model – the location of all avatars and objects, all ownership rights, all entity
types, all tasks executed, and all changes – in short, a system that could provide full
visibility. We explore this question by considering a subproblem – how to build a supply
chain management system that tracks the avatars, assets (equipment) and inventory
(supplies) within the domain of a hospital.
The resulting architecture provides a simplified tracking system for the 3D virtual
world Second Life, consisting of a DBMS connection via http post requests to PHP
scripts, and a simplified database schema with three tables, entity and asset, and
location. Queries to the tables can locate avatars, equipment or supplies; provide
inventories; or track histories of items which can be used for recalls.
This thesis is approved for recommendation to the Graduate Council.
Thesis Director:
____________________________________
Dr. Craig Thompson
Thesis Committee:
____________________________________
Dr. Brajendra Panda
____________________________________
Dr. Gordon Beavers
THESIS DUPLICATION RELEASE
I hereby authorize the University of Arkansas Libraries to duplicate this thesis when
needed for research and/or scholarship.
Agreed ________________________________________
Alex Ahmad
Refused ________________________________________
ACKNOWLEDGEMENTS
I thank Dr. Craig Thompson for directing my masters studies. I also thank Dr.
Gordon Beavers and Dr. Brajendra Panda for serving on my thesis committee.
I thank my father Dr. Mike Ahmad for his support and motivation as I completed
my studies.
v
TABLE OF CONTENTS
1. Introduction .................................................................................................................. 1
1.1 Problem .................................................................................................................... 1
1.2 Thesis Statement ...................................................................................................... 2
1.3 Approach .................................................................................................................. 2
1.4 Organization of this Thesis ...................................................................................... 4
2. Background .................................................................................................................. 6
2.1 Key Concepts ........................................................................................................... 6
2.1.1 Ubiquitous Computing, Identity Management and Full Visibility ................... 6
2.1.2 Metaverse, Virtual Worlds, Second Life .......................................................... 9
2.1.3 Supply Chains and RFID ................................................................................ 10
2.2 Related Work on Logistics in Second Life ............................................................ 11
2.3 Related Work on Healthcare in Second Life ......................................................... 12
3. Connecting a Logistics DBMS to Second Life ......................................................... 14
3.1 Overview ................................................................................................................ 14
3.2 Developing the Database Connection .................................................................... 14
3.2.1 Roadblocks to Database Connection in Second Life ...................................... 15
3.2.2 Simple Schema and Queries ........................................................................... 17
3.2.3 Connecting Second Life to a Remote DBMS ................................................. 19
3.3 Developing a General Monitoring System ............................................................ 20
3.3.1 Roadblocks for General Monitoring System .................................................. 20
3.3.2 General Monitoring System for Second Life .................................................. 21
vi
4. Supply Chain Queries ................................................................................................ 24
4.1 Overview ................................................................................................................ 24
4.2 Simple Supply Chain Queries ................................................................................ 24
4.2.1 Find Entity Query ........................................................................................... 25
4.2.2 List Inventory Query ....................................................................................... 26
4.2.3 Track Entity Query ......................................................................................... 26
4.3 Modeling a More Realistic Supply Chain .............................................................. 27
5. Conclusions ................................................................................................................. 31
5.1 Summary ................................................................................................................ 31
5.2 Contributions and Potential Impact ....................................................................... 31
5.3 Future Work ........................................................................................................... 32
References ........................................................................................................................ 35
Appendix A ...................................................................................................................... 37
Appendix A.1 ................................................................................................................ 37
Appendix A.2 ................................................................................................................ 40
Appendix B ...................................................................................................................... 44
Appendix B.1 ................................................................................................................ 44
Appendix B.2 ................................................................................................................ 46
Appendix C ...................................................................................................................... 47
vii
LIST OF FIGURES
Figure 1: Results for location query................................................................................. 25
Figure 2: Results for list of items in the pharmacy .......................................................... 26
Figure 3: Results for track query ..................................................................................... 27
viii
1. INTRODUCTION
1.1 Problem
The “Everything is Alive” project at the University of Arkansas in Fayetteville is
focused on pervasive computing:
“In the future, individual toys will have personalities and will play with children
and each other; they’ll help children learn to read and do their homework. The
sprinkler system will communicate with your yard’s plants to see how much water
each needs and scan the weather channel for news of rain to adjust water rationing
accordingly. While exercising at the gym after work, you’ll be able to ask the
weight machine to tell your oven at home to turn on at 6:30 p.m. because you’re
running late. As you walk to your car, you’ll answer a call from your mother and
have a good chat while driving to the shopping mall — all without a visible
phone. The clothes racks at the mall will sense your profile and accentuate the
right sizes and styles as you walk by. After you purchase a new jacket, wearable
computing embedded in the cloth will begin operating on your behalf. At the
grocery store, you’ll just pick up the items you want and sensors in the store will
automatically debit your grocery account as you leave.” [1]
Already RFID, the vanguard of a coming sensor-rich world, is beginning to
provide the ability to track objects and people in retail supply chains, healthcare and other
business domains.
Though the military has explored multiuser simulations and game playing for
some years, the ability to model other kinds of complex domains like retail and
healthcare is just now being explored in virtual worlds. The 3D virtual world Second
Life offers a test bed platform where we can try experiments in ubiquitous computing
and, with additional work, simulations.
1
This thesis focuses on the problem of how to use a database management system
(DBMS) to model a healthcare facility (in our case, a hospital) that is represented in the
3D virtual world Second Life (SL). Things1 that need modeling include:

Identity - where entities are now and who is responsible for what - the identity of
avatars and objects in terms of type, location and ownership;

Inventories – what objects are in a place like a delivery truck, a supply room, on a
cart, or in a patient’s room; and

Track history – the history of where things have been.
1.2 Thesis Statement
The objective of this thesis is to tie an external DBMS model of avatars, objects,
and their attributes to a virtual world (Second Life) to be able to demonstrate (a) finding
things, (b) identifying inventories in a place, and (c) determining track histories of avatars
and things.
1.3 Approach
Second Life uses its own internal relational DBMS to represent items of interest –
but this DBMS is not available for user queries.2 In order to make it possible to collect
information about objects, we needed to develop two components – a tracking system
within Second Life and a connection to a remote relational DBMS where we could store
1
The term things is used here in the same sense as it is used in the pervasive computing phrase, Internet of
Things or Things that Think, similar pervasive computing visions to the Everything is Alive vision.
2
The recently available open source server for Second Life (OpenSim) similarly provides an internal
DBMS and this DBMS is accessible to developers. Implementing our basic and complex queries in this
DBMS and extending it to cover workflow tasks is an interesting future direction.
2
information we collected from the tracking system. We also need a way to display or
visualize object locations in Second Life.
In our approach, for simplicity, one DBMS was used to log all of the information
about all entities (objects and avatars). For example, when an entity “A” leaves location
“X” and goes to or is transported to location “Y”, a sensor at location “X” senses and
records the entity’s location. When the entity arrives at location “Y”, a sensor at location
“Y” captures and records the change of location. This way, we can track when an item is
at the warehouse, when it is loaded into a truck, when it is transported to the hospital
loading dock, and when it arrives at a supply room. While, normally, this information is
stored in different DBMS systems (managed by different information owners, stored in
proprietary heterogeneous schemas), for the purposed of this thesis, we simplify and
assume all data is stored in a common supply chain schema and accessible from one
master DBMS.
These simplifying assumptions makes it easier to consider the main issues in this
thesis – that is, the kinds of queries that supply chains need to pose. We wanted to
identify a collection of kinds of queries that would be useful for keeping track of avatars
and objects. We classified these queries as basic or complex. This thesis focuses on
simple logistics queries because our purpose is to show how to connect a logistics system
reflected in Second Life to a remote DBMS. The basic or simplified types of queries we
consider include:

Finding things: In the real world, nurses spend considerable time looking for
things they need. Sometimes, they cache them locally (even hide them) so that
they will have them when they need them.
3
But that makes these items
unavailable for other uses. In order to find things in our Second Life hospital, we
use sensor(s) that capture all of the traffic that is going on in the hospital. Then,
we simply log the information into a database and define a basic query that will
retrieve the location information about an object or avatar.

Inventories: Associated with a place and owners, an inventory is a listing of all
objects on hand and may include additional information about reorder points. We
want to be able to list inventories of places in Second Life. To do this, we
extended the tracking system to keep record of the location and owner of every
object and the location of every avatar. A simple query can list all objects or
avatars located in a place or owned by an owner.

Track histories (provenance): We want to be able to keep track of the history of
an object – where it has been. Whenever we log a move for an object or avatar,
we keep this information in the database and whenever we want to retrieve the
data, our SQL query retrieves all entries for that entity.
A number of real-world complications to the simplified supply chain model are
identified that would make these queries increasingly realistic – but a full model of a
realistic supply chain model is not the aim of this thesis so we leave a more complete
model of a realistic supply chain to future work, only identifying some of the issues in
this thesis.
1.4 Organization of this Thesis
The outline of this thesis is as follows. Chapter 2 provides a general overview of
ubiquitous computing, virtual worlds, and supply chains. Chapter 3 describes the
tracking systems and the DBMS connection to Second Life that we developed. It also,
4
shows the results of executing some of the queries. Chapter 4 describes the basic queries
and how they can be implemented. It also describes issues that would make the supply
chain more realistic but also more complex.
Chaper 5 summarizes the thesis, describes
its contributions and suggests areas for future work.
5
2. BACKGROUND
2.1 Key Concepts
This project grew out of the author’s class project in the CSCE 5043 Artificial
Intelligence course in the Computer Science and Computer Engineering course at the
University of Arkansas completed in Spring 2008. That project demonstrated that it is
possible to connect a remote program (in this case, a database system) to the virtual
world, Second Life to communicate with Second Life. The result was the ability for an
avatar to send a message to the remote DBMS to record its location. This led to the
question whether it would be possible to automatically and unobtrusively track all
movements of selected avatars and assets in an environment like a hospital.
This thesis depends on three key technology areas: ubiquitous computing, virtual
worlds, and supply chains.
2.1.1 Ubiquitous Computing, Identity Management and Full Visibility
The synonymous terms ubiquitous computing and pervasive computing refer to a
trend where computers escape the desktop and the laptop to become part of the fabric of
every item around us – devices, objects, our clothing, and even pets. Already, we see this
happening with ever present cell phones becoming smarter and radio-frequency
identification (RFID) tags beginning to be used to mark the explicit identity of any item.
Putting these together, there are already cell phones with RFID readers so it should soon
be possible to use your cell phone to point to an item at the store to gain more
information about that thing – similar to a URL. We sometimes refer to this vision of the
future, where the Internet has spilled out into the real world, as the Internet of Things.
6
At the same time, storage capacity is increasing and we continue to generate more
and more data. Where cavemen modeled the world by knowing where to find food or
shelter, modern computers model a slice of the world in one or many applications. For
example, the University of Arkansas uses a system called ISIS to keep track of its
students, their courses, and their grades but ISIS does not keep track of who their friends
are, where they are right now, and many other aspects of their life on campus. Other
databases keep track of rent, bank accounts, electricity usage, credit card purchases,
permissions to access buildings, purchasing behaviors, demographics, building plans,
computer connectivity, and Internet histories. Phone records track conversations and cell
phones can track location.
This leads to questions, what if all the above information could be aggregatged
and beyond that, can we record virtually everything that happens to us? MyLifeBits [2] is
a project at Microsoft that is aimed at allowing a person to capture, store, classify,
analyze and search data representing their entire life [3]. Capturing video of every
waking moment, listening to all phone calls, archiving all instant messanges, mail, TV,
calendars, and meeting notes; every single moment is indexed, tagged and searchable.
This requires terabytes of storage capacity every month but many people can afford this
much storage.
Total Information Awareness [4] (TIA) was a DARPA program based on a vision
of assembling as much information as possible about as many people as possible into a
database, making that information available to government officials and sorting through it
to try to identify terrorists. Congress canceled the TIA program because the program was
criticized by the public as creating Big Brother, a world with little privacy where big
7
government knows everyone’s business. More recently, the ability to record all objects
in industrial supply chains has been viewed as a breakthrough because it provides the
ability to have “full visibility” – to know how to locate objects in supply chains and warn
if their progress is slowed or they experience problems (e.g., too hot or cold) along the
way. Technologies and systems related to identifying a collection of things of interest are
called identity management systems. Examples are management systems for drivers
licenses, student IDs, pet IDs, livestock IDs, and many more.
In his paper “Everything-is-Alive” [1 – see quote in Section 1.1], Thompson
describes a smart world of the near future where humans and things can communicate
with each other. Looking at the world today and ten years ago, it is apparent that
everything is becoming alive and we are moving closer to this smart world vision.
Elevators talk to us; doors open when we approach. Our GPS tells me where to go. Our
cable DVR records the shows we want to see, even resetting if the show is off schedule.
Ten years ago, objects did not talk to us or tell us how to navigate the world.
The technological singularity [5] is “a theoretical future point of unprecedented
technological progress, caused in part by the ability of machines to improve themselves
using artificial intelligence.” I. J. Good posited that once machines surpass humans in
intelligence, they can thereafter very rapidly improve. V. Vinge termed this event "the
Singularity." We may not be approaching the singularity in the near future (especially in
terms of a computer’s ability to use common sense reasoning), but it seems likely that
being able to model the real world to the level of individual objects and their locations
and owners is a useful step in that direction.
8
2.1.2 Metaverse, Virtual Worlds, Second Life
A virtual world is a computer based simulated environment intended for users to
interact and communicate. A metaverse is a virtual world, where humans interact with
each other and software agents. Users appear as avatars of any form and can access the
metaverse through personal terminals. The avatars are depicted as textual, two
dimensional, or three dimensional graphic representations. Most people think that virtual
worlds are limited to games but some virtual worlds are more advanced and can
encompass computer conferencing and provide 3D chat. Some virtual worlds are built to
model or simulate the real world and thus use rules based on the real world.
Second life [6] is a virtual world that was lunched in 2003 by Linden Labs.
OpenSim is a open source system compatible with Second Life servers. In Second Life,
avatars can meet each other, socialize and participate in social group activities. Second
Life allows its users to build objects using a 3D modeling menu and also to activate them
using an event-driven scripting language called Linden Scripting Language (LSL) which
is similar to JavaScript. The scripting language can be used to add functionality to the
objects using built in functions or by creating new functions. Most other gaming
environments do not include the twin features of building and scripting.
While Second Life offers building and scripting functionality, it falls short of
providing a mature environment in which to model and simulate. Since our project is one
of the first to try to use virtual worlds in this manner, we can list some general roadblocks
we encountered that will need to be addressed before Second Life will be a usefully
robust modeling and simulation environment:
9

Import-export – Second Life does not provide functionality for importing content
like contour maps, building plans, or CAD models of objects. There is not even a
good way for end users to move such objects from one Second Life grid (the teen
grid, for instance) to another.

Ontologies and Workflows – Second Life does not provide any built-in ontology
or knowledge representation support for distinguishing the type of an object
(beyond an optional descriptive name). There is no language for orchestrating
avatar-bots to follow sequences of scripts to execute higher level worlflows.
Indeed, Second Life is primitive in some other ways as well. The physics engine
permits a user to shove an object through a wall and makes it exceedingly difficult for
an avatar to pick up objects using their hands or to push one object containing other
objects from place to place. Other students at University of Arkansas are working on
projects to remove these and other limitations of the virtual world platform to make
modeling and simulation easier.
2.1.3 Supply Chains and RFID
Radio frequency identification (RFID) is “a wireless identification technology
that relies on cheap tags (transponders) that can be attached to objects (such as pallets,
containers, ID badges, assets, vehicles, and pets) and that nearby readers can track.” [7]
Although it is not new, RFID technology has dramatically improved in recent years,
resulting in cheaper tags (now costing less than 10 cents) and higher read reliability.
RFID chips are designed to augment bar codes. EPCglobal Inc., the standards
body that manages UPC (Universal Product Code) information in bar codes, sets the
standards for how basic product information is encoded in RFID chips.
10
Because RFID is in the early adoption stage, many companies are still trying to
assess the business case for it. A recent study suggests that RFID can significantly help
with the common retail-industry “out of stocks” problem (products that should be on the
shelf but are not) [8]. Early adopters also face the problem of determining which
hardware and software investments to make because every RFID reader and printer
presents a different interface and systems are not yet interoperable.
In a typical warehouse, trucks back up to a dock door to unload pallets of goods.
The pallets and containers on the pallets can have RFID tags, but, at present, few lowcost items (packed inside the containers) have their own tags (for cost and consumerprivacy reasons) though that is rapidly changing especially in the apparel industry. RFID
readers might be situated throughout the warehouse at places such as dock doors or doors
leading into stores. By reading tags, organizations can trace their pallets and containers
as they move throughout the resulting supply chain.
2.2 Related Work on Logistics in Second Life
The field of using virtual reality in simulation and modeling has been explored by
for training exercises by the US Department of Defense Modeling and Simulation Office,
which developed the High Level Architecture standard for federating simulations build
by different parties [9]. The field of using virtual reality in logistics simulation models is
relatively unexplored. A survey article [10] outlined several potential uses of 3D virtual
worlds related to logistics, concluding:
“The ability of Virtual Reality to provide realistic simulations of data, objects and
environments, with which users can interact and manipulate in an intuitive and
realistic manner, opens up a vast wealth of possibilities for Logistics systems
applications.” [10, p. 383]
11
A literature search of Citeseer using keywords “logistics” and “supply chain” with
“virtual world” and “Second Life” did not yield results. Google searches using the same
terms yield blogs and other websites – several of which mention our project’s web site
(http://vw.ddns.uark.edu).
Virtual RFID readers and tags were developed in Second life by an earlier student
project at the University of Arkansas [11]. Virtual readers set a field as an invisible (or
semi-transparent pink) semi-spherical collision zone. If an object with a virtual RFID tag
collides with the zone, a tag read occurs. This message is sent as a Second Life chat
message which can be directed to the DBMS if sent on the DBMS chat channel
#1099254.
2.3 Related Work on Healthcare in Second Life
Below is a list of other healthcare projects ongoing in Second Life. All have a
different emphasis than ours. Ours is especially focused on information technology,
logistics, workflow, smart devices, and scripting. Other Second Life sites are focused on
architecture, education and training as described below.
The Ann Myers Medical Center [12] aims to help students in multiple areas of
healthcare. They provide students with training in the analysis of MRIs, CTs, and Xrays. AMMC currently has a voluntary staff consisting of psychologists, hematologists,
oncologists, radiologists, cardiologists, midwives, emergency and trauma specialists and
several nurses.
Health Info Island [13] focuses on information distribution and community
building. The project contains informational links and a small list of community
members you may talk to (via instant messaging) if you need help.
12
Second Health [14] is a virtual hospital setting in Second Life. The Second
Health project is working with the UK's National Physical Laboratory and the Imperial
College London. Second Health has a very nice looking campus and includes
educational videos focusing on keeping healthy. The setting includes a realistic setup and
informational note cards but includes very little scripting overall.
The UC Davis Virtual Hallucinations site [15] lets you experience a brief bout of
schizophrenia. You begin by picking up a virtual badge and then walking down a
hallway where several things will start talking to you.
Cisco and Palomar Pomerado Health [16] opened a virtual hospital in February
2008. The architectural floor plan matches the hospital, which will open in 2011. Ideas
they intend to explore include telepresence, robotic simulations, communications, 3D
holographic imaging, and sensor-based tracking including RFID.
IBM Healthcare Island may be the closest to ours but that island is proprietary and
not accessible to the public where our University of Arkansas island is open to visitors.
At the time of this thesis, we are unaware of any other efforts to use DBMS
systems to model healthcare logisitics in a virtual world.
13
3. CONNECTING A LOGISTICS DBMS TO SECOND LIFE
3.1 Overview
In a real hospital, nurses and doctors need equipment and supplies when they need
them. They often have to search for these items. Sometimes they cache the items nearby
so they will have them when they need them, meaning either other needs go unmet or the
hospital must carry a larger than necessary inventory. In a real hospital, various
management systems (that may or may not be interconnected) may or may not manage
these items.
Our project’s overall goal is to track objects and avatars in the hospital in order to
keep track of the hospitals supplies inventory, equipment assets, patients, nurses, and
doctors. Our virtual world hospital project requires some way to keep track of patient’s
information, equipment usage, and the supplies inventory. This problem breaks down to
two other problems:

how to record all the location and history information – the database connection;
and

how to sense changes in the virtual world – the monitoring system
3.2 Developing the Database Connection
The purpose of the database connection is to provide a way to connection the
virtual world Second Life to a remote database so selected changes in the virtual world
can be recorded in the remote DBMS and so the state of that DBMS is queryable from
within the virtual world.
14
3.2.1 Roadblocks to Database Connection in Second Life
At the beginning of this thesis work, scope and requirements were considered,
beyond the class project. It was decided to monitor, log, and query not just locations of
avatars but locations, inventories, and track histories of selected avatars, assets, and
inventory – but only within our virtual hospital.
Several possibilities were considered for storing the log.
One possibility was to use Second Life’s internal relational DBMS. In current
Second Life, state information internal to the virtual world is stored as relational tables or
files. It took some time to discover that Second Life does not offer an API for extending
this internal DBMS, not surprisingly as allowing users to add new applications could
overwhelm existing virtual world performance.
A second possible way to store state information might be to use in-game data
structures. Alternatives considered included:

Use the documentation string associated with every Second Life object. This
field is intended for descriptions, however, and is limited to 127 characters. Other
than direct access, there is no query capability; furthermore, users may choose to
use this string themselves.

Use Second Life note cards to store configuration values as delimited text files,
but, after learning more, it turned out that note cards are read only which would
not allow us to append or update data.

Use scripts, which can pass data to each other as a possible way to store
information about objects, however, the data would be lost when the objects are
restarted.
15
Based on these experiences, it appears that one cannot use Second Life itself to store the
DBMS log.
Our original class project implementation of a connection to an external DBMS
seemed like it offered the best possibility for storing the log but it too had problems. That
project considered how to connect Second Life to an external database using an ODBC
connection. Second Life’s API provided an XML-RPC which can be used to send XML
data over HTTP that a remote system then handle. Determining how to use this and
connect it to an external Apache server took several weeks. PHP was used to parse XML
sent from Second Life. While it was possible to complete the functionality of the class
term project permitting avatars to log their locations in a remote database, this database
connection had problems. The connection would intermittently fail especially when
querying for large amount of data. Reading more documentation, it became apparent
that XML-RPC often times out due to the front-end server being overloaded which is a
Second Life code reliability limitation. Assuming that Linden Labs would soon fix this
problem permitted me to focus on how to build a sensor network in Second Life
(described below), but Linden Labs upgrades on the server hardware did not fix the
problem.
Instead, Linden Labs suggested using HTTP polling instead of XML-RPC
because the former design is not scalable and the server is deprecated due to a single
server bottle neck. Reimplementing the database connection using llHTTPRequest
allowed sending data from Second Life to a specified URL that executes a query. A
second Second Life function called llHTTPResponse is used to receive a response
following an llHTTPRequest. Using this implementation, the database connection
16
can now reliably send information to a remote DBMS or request information from a
remote data source at a known URL and then receive a response and then print the
information on the chat channel. It took about four weeks of development and testing to
improve the database connection for reliability. A simple DBMS scheme was
implemented which I will explain in the next section of this chapter.
3.2.2 Simple Schema and Queries
Second Life creates a unique ID for each avatar/object in the hospital so this will
be the key that we use to identify the entries for objects and avatars in the database.3
The first step was to define a simple database schema using three tables,
entity, asset and location. The entity table provides a unique identifier for
any individual entity as well as a description of that entity and a type for that entity.
CREATE TABLE IF NOT EXSISTS `entity` (
`entityID`
int(11)
NOT NULL auto_increment,
`description` varchar(100) default NULL,
`entityType`
varchar(20) default NULL,
PRIMARY KEY (`entityID`)
) ENGINE=MyISAM
DEFAULT CHARSET=latin1;
The asset table treats some entities as assets and records their location and region. A
region is a larger place like a hospital, or warehouse. This field was implemented so that
we can use the same location name for more than one region. i.e. Hospital has an Office
and a Warehouse has an Office.
CREATE TABLE IF NOT EXISTS `A` (
3
It is worth point out that the Second Life system does not name things. A SL inventory item simply
consists of a collection of prims (primitive objects). In SL itself, there is no way for the system to tell a
door from a castle. Our entity and asset tables can be viewed as a simple ontology system for naming
or typing things.
17
`assetID`
int(11)
`entityID`
int(11)
`regionCode`
varchar(20)
`locationCode` varchar(20)
PRIMARY KEY (`assetID`)
) ENGINE=MyISAM
DEFAULT CHARSET=latin1;
NOT NULL auto_increment,
NOT NULL,
default NULL,
default NULL,
The Location below lists objects and avatars and how long they spend at a
location (or in a region). The ID is the primary key; Start_Date is the date and time
the collision happened; End_Date is the date and time the collision terminated; Name is
the name of the avatar/object; Key_ID is the Second Life unique ID for the
object/avatar; Region is the location in Second Life that the collision happed; Flag is
used to store wether the collision is still active or inactive; and the Comment field (not
currently used) was implemented to store extra information about an object.
CREATE TABLE IF NOT EXISTS `location` (
`ID` int(11) NOT NULL auto_increment,
`Start_Date` datetime default '0000-00-00 00:00:00',
`End_Date` datetime default '0000-00-00 00:00:00',
`Name` varchar(100) default NULL,
`Key_ID` varchar(200) default NULL,
`Region` varchar(100) default NULL,
`Flag` char(2) default NULL,
`Comment` text,
PRIMARY KEY (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
The second step involved defining a PHP function to perform the three operations
select, insert, and update on the entity and asset tables depending on the
parameter that we send to it from Second life. There are five functions in this PHP code,
listed below. The PHP code is provided in Appendix A.1.
18

cmd_addent - if we send the parameter ADDENT with the variables id, descr,
and type, the function cmd_addent will be called and perform insert operation on
the entity table.

cmd_getent - retrieve the data from the entity table

cmd_addast - insert a record into the asset table

cmd_getast - retrieve data from the asset table

cmd_delent - deletes data from the entity table by setting a delete flag to I as in
inactive.
3.2.3 Connecting Second Life to a Remote DBMS
A communication method is needed to connect Second Life to the PHP function.
To implement this connection, we use the LSL command llHTTPRequest (string
url, list parameters, string body). To insert a record into the entity
table, we send the parameter addent followed by the variable id, desc, and the entity
type separated by delimeters. This calls the PHP function cmd_addent by sending a
post request to the URL. The || is our delimiter and whenever data moves between a
Second Life script and a PHP page, it identifies the data by field position.
Scripts in Second Life must be associated with some object. Consequently, we
developed an object that contains the general database communication script. The code
associated with this object is provided in Appendix A.2. We deployed the
communications object using Second Life’s chat channel #1099254 for security purposes
so no one can communicate with the database unless they know the channel number
19
(security by obscurity). By creating this simple database we are able now to insert,
update and select from the data base.
3.3 Developing a General Monitoring System
The purpose of the General Monitoring System is to provide a sensing system so
selected changes in the virtual world Second Life can be monitored. A record of these
changes can be stored in the Database Connection discussed in the previous section.
3.3.1 Roadblocks for General Monitoring System
As mentioned in section 2.2, virtual RFID readers were implemented in Second
Life in an earlier student project [17]. They could be used to detect avatars or objects
with attached virtual RFID tags – but they could not be used to track avatars or objects
that do not have RFID tags attached to them. In order for us to track objects/avatars, we
need another method of tracking. Reviewing the Second Life API, the function called
llSensor provided a means to perform a single scan for name, ID and type within a
range. Over a two week period, an implementation was developed for a sensor system
using llsensor and seemed to work to detect the movement of avatars and objects in a
sensing region. While developing other functions to help improve the sensor, it became
apparent that llsensor does not detect all of the objects in a sensing region. Testing
revealed that llSensor can only scan sixteen objects at one time. The maximum
number of objects that can be detected is sixteen at any giving time. Another problem
was that llSensor will not detect objects that have other objects attached to them. For
example, if a truck has a dolly attached to it, then llSensor cannot detect the dolly.
20
These limitations in llSensor functions did not allow us to track every object in
certain place (like an inventory of a supply room containing more than 16 items) or
objects that were attached to other objects.
The next section describes how an improved monitoring system was developed
using other Second Life functions to track all items in an inventory.
3.3.2 General Monitoring System for Second Life
In order to track all objects and avatars in the hospital, we needed a tracking
engine that captures all inventory movement and asset transfers in the hospital and a way
to store all of this information in a remote database. Above, we discussed how
information records are transferred to a remote DBMS. In addition, we needed to
develop a region-wide movement sensor that would be triggered each time an object or
avatar is moving in any location/region in the hospital. Second life does not offer a
builtin function that will work as a sensor but it has a function called
llVolumeDetect which detects any communication between an object and any other
objects or avatars. In addition, there needed to be a way to trigger a sensor object’s script
to run each time there is a movement and to stop running when there is no movement.
Second life has another function called Collision_Start which is triggered when an
object starts colliding with another object. We can use IIVolumeDetect to detect a
collision, and we can tell the sensor object to start running when there is a collision.
We also needed a way to place such a sensor object in the hospital without
interfering with other objects. Since this object gets triggered when another object
touches it, it is not possible to tell everyone and everything to touch the object each time
21
they move. To solve this, we made the sensor object invisible and as large as an area of
the hospital that we wanted to monitor. The sensor object contains a script that runs each
time any object/avatar goes though it. Second Life can hide the sensor object (if its
alpha property is set to zero) and allow any other objects or avatars to go though it.
Since avatars can fly, we needed a way to track avatars that are flying. We can
set the size of the sensor to fit a whole location height and width so that, whether an
object is flying or moving along the ground, we can still detect it.
The initial implementation of the sensor object ran into two problems. The first
problem was how to tell the sensor that the object/avatar has left the sensor region? A
Second Life command Collision End triggers each time an object or avatar stops
colliding with the sensor so that function was used to tell the sensor that the object/avatar
has left the sensor region.
Thesecond problem was that the sensor object wrote multiple entries in the remote
database’s location table. Analyzing this problem revealed that every time an object
or avatar collides with the sensor, a volume will be detected which will run the collision
start function, which resulted in inserting a record into the database for every object or
avatar within the sensor region even if they already been detected. This was expensive in
database access aside from leading to confusing results. The solution to this problem
involved implementing a variable within the Collision_Start function that stores
the object or avatar name for entities that are currently within the sensor region. When
another collision happens, the Sensor function thereafter only sends an HTTP request to
insert new records to the database, no longer re-logging entities that had earlier been
detected. This solved our problem of having multiple entries. Implementation and
22
testing of the sensor object took about 8 weeks resulting in a sensor that will track any
object or avatar. The sensor code is provided in Appendix B.2.
In addition to developing sensor objects, we needed a way to name the location
where the collision happened. To accomplish this, we deployed a collection of sensor
objects and named the corresponding locations in the virtual hospital. Examples of
names can be “central supply room,” “supply cabinet in room 234,” and even “cart 15”
for mobile sensors attached to a vehicle.
Whenever an object collides with a sensor, a Second Life script runs that sends a
record to the DBMS. An avatar or object can leave one sensor region and later enter
another sensor region – recorded as an object removed from one named inventory (or
place) or added to another inventory (place).
23
4. SUPPLY CHAIN QUERIES
4.1 Overview
Chapter 3 also described the implementation of a tracking system for Second Life.
In this chapter, we consider logistics queries. Accoding to Wikipedia,
“A supply chain or logistics network is the system of organizations, people,
technology, activities, information and resources involved in moving a product or
service from supplier to customer. Supply chain activities transform natural
resources, raw materials and components into a finished product that is delivered
to the end customer.” [7]
In this thesis, we (initially somewhat simplistically) model a supply chains as a
sequence of places, called inventories. An item (or avatar) can be associated with one
place, then later with another place. The simplistic model is a reasonable first
approximation used in this thesis. We leave to future work the development of a
realistically complex logistics supply chain.
4.2 Simple Supply Chain Queries
Having built the tracking system described in Chapter 3, we developed a Second
Life green board Display object, which is where the Second Life retrieval functions
reside and result displays are shown. When we send a request (as will be described
below) to this object on Second Life chat channel 109, it executes the appropriate
command and show the results on the Green board.
It takes less than a second to retrieve the data from MySQL depending on the
query that you perform. The code behind this engine has three main functions: Where,
List and Track . Chatting Where is || ID on Channel 109 calls a PHP function
24
that will run a select query that looks for any object/avatar with the ID sent to it. The
List and the Track functions operate similarly except they perform a different select
query. The code is provided in Appendix C.
4.2.1 Find Entity Query
Figure 1 shows the results of the location query.
Location query: /109 where is ||
12dcceb0-a965-4a53-b489-27c869a6202d
Figure 1: Results for location query
The long number after the || is the ID of the requesting avatar (an avatar in this case).
/109 is the channel that was used to communicate with the DBMS engine. As soon as
the object receives this call, it triggers the function called whereis, which will send a
post to the PHP function called whereis. Then, the PHP function called whereis
generates the following SQL:
Select * from Location
where Key_ID=”12dcceb0-a965-4a53-b489-27c869a6202d
and Flag=Y
The results return the entity name, location and date/time where the object/avatar
with the requested ID is located, which is in the supply room 2 in this case. The field
25
“Flag” is “y” when an avatar is in the location and “N” when an object is in the location –
and that’s the indicator for this particular query.
4.2.2 List Inventory Query
Figure 2 shows the results of the list query.
Lists of items in a location: /109 list objects in ||
Pharmacy
Figure 2: Results for list of items in the pharmacy
This query lists all objects that are currently in the Pharmacy. The SQL that the PHP
function generates looks like this:
Select * from Location
where Region=”Pharmacy”
and Flag=”Y”
The query will return all of the items in the Pharmacy that have the value “y” in
the “Flag” field which is as mentioned before the indicator that the object/avatar is
currently active in a certain location.
4.2.3 Track Entity Query
Figure 3 shows the results of the tracking query.
Track query: /109 track ||
26
12dcceb0-a965-4a53-b489-27c869a6202d
Figure 3: Results for track query
This query lists all locations that an entity (in this case, an avatar though it could be an
object) has been to in the hospital and the time/date of the visit. The SQL that the PHP
function generates looks like this:
Select * from Location
where Key_ID =”12dcceb0-a965-4a53-b489-27c869a6202d”
The query returns all entries in the Location table that have the provided Key ID.
Tracking can be used to determine an entity’s provenance or history.
4.3 Modeling a More Realistic Supply Chain
As mentioned, our supply chain model is simple, even simplistic. The rationale
for leaving it simple is that there are many ways it can be complicated and, since our
larger project’s goal is to extend Second Life in numerous ways to make it a better
platform for serious modeling, it is less important to develop a complex logistics model
that will potentially confuse future students than to include a simple model now and leave
realistic logistics modeling to later student projects. Different organizations model
27
logistics differently so it is likely that, in the near future, one size does not fit all. That
said, it is worth noting some of the ways the model is too simple (areas for future work).

Moving inventories – some inventories (places) move as when goods are being
carried from place to place by a truck or cart. This is fairly straightforward to
model for us as we can attach sensor scripts to vehicles like trucks or carts. In this
case, the place itself is relative to SL’s absolute coordinate system.

Location is not the same as ownership – some inventories contain items owned by
one party but others might contain items-on-consignment or rented – so physical
placement is not the same as ownership. We’d need to model ownership
separately. Often, in a supply chain, there is a close relationship between location
and ownership – but not always.

Hierarchical locations – some inventories can be distributed or arranged in a
hierarchy, so the supply cabinet inventory can be in the supply room which is in
the hospital. Similarly the Cath Lab personnel may be responsible for some
things (like Cath Lab procedures) but the containing hospital is ultimately
responsible for others (like paying salaries).

Logistics modeling – more sophisticated inventory management systems
distinguish quantity on hand from reorder point and provide automated methods
for insuring that some critical items are always on hand or can be acquired in a
timely manner (e.g., via service level agreements). We could extend our supply
chain model to cover reordering strategies to keep the supply chain lean but full.
Complex business rules can identify when to reorder based on expected specials
28
or whether running out of an inventory item is an inconvenience with a generic
alternative available or a life threatening situation.4

Attributes – Some objects have special features like battery life of equipment;
expiration date of food, temperature range, readiness; or maintenance
requirements.
Some of these affect the supply chain – for instance, food
subjected to higher temperatures may spoil and be disposed of or may ripen faster
and so should be sold first. Equipment within a hospital needs to be sterilized
after use – its status is not ready until it has undergone this procedure, then its
status become ready.

Aggregations – trucks, pallets, containers, or pre-sterilized surgery packs may
have their aggregate identify but also may contain items that have their own
individual identities.
In a supply chain, moving an aggregate object moves its
contained objects. At some point, aggregates are unpacked (disaggregation) and
then the aggregate ceases to exist and the contained objects can separately move. 5
4
One reason we deferred modeling reordering was that we are working on workflows executed by
avatarbots. Second Life, minus avatars, is a lonely place. Avatarbots (avatars run by a program rather than
a person) can populate the hospital with activity: operations, caring for patients, etc. And these workflows
use equipment and supplies. The equipment then needs other workflows (sterilization, recharged) before it
is ready again. And the supplies need to be reordered. We expect to implemement automated reordering at
that point.
5
Author’s note: When purchasing an item in bulk and using it as a single item, how do we tell the
inventory the quantity of items that we have? I am a web programmer at an on-line coffee store and we
purchase items in cases and then sell them in singles.
We solved the aggregation problem by building our purchase order (PO) system in a way that will
tell the inventory system the actual quantity of items that we purchased. For example: We have item
CTM01 that we purchase in a case that contains 4 boxes. The PO system is built in a way that will allow
the buyer to: enter the item code, the quantity that they want to purchase and the number of items that are
packed in each case. Then the system multiplies the number of items in each case with the quantities that
the buyer purchased and then tells the inventory when the buyer received says 6 cases multiplied by 4
boxes which equals 24 items.
This solved our problem of purchasing and receiving but what if we want to use or sell this item
by the case? To solve this problem we introduced a bundling solution. Basically a bundle item is a child of
a parent item. You can build an item in your system that feeds on another item but this item is sold in cases
29

Access control – only the right person should have access to an item. In some
applications (e.g., narcotics), there is a strict “chain of custody” that assures no
third party has access to an object except at well defined handoff points. Also,
some objects and people should stay within a defined area – so we will eventually
need to add a perimeter management capability.

Tracking history across organization boundaries. We want to track objects as
they move from place to place, from owner to owner, even when the object
crosses organizational boundaries. In some cases, at such a juncture, the object
identity is maintained the same but in other cases, it is given a new identity local
to the new organization.
so if someone purchases 3 items of a bundle item they actually purchased 3 multiplied by the number of
items in the case of that item.
30
5. CONCLUSIONS
5.1 Summary
In this thesis, we developed and explored a system for modeling logistics
management in a health care domain using a 3D virtual world. A supply chain database
schema was implemented which included implementing a chain of sensors. Using this
sensor network, we are able to track all the movements in the hospital down to the level
of individual pills and cotton balls. Based on the data collected, we can track which
avatars or objects are in a certain room in the hospital - a query that many hospitals
would benefit from.
5.2 Contributions and Potential Impact
This thesis contributes to our understanding of pervasive computing and shows
how this can be beneficial in one application domain, healthcare.
We developed a DBMS system that provides “full visibility” to every avatar or
object in Second Life. The system is demonstrated in a hospital setting but can be used in
any Second Life application domain.
We demonstrated the ability to track objects and personnel, assets, and supplies in
a hospital. So if a nurse needs a blood pressure machine, s/he can request the system to
display a list of available machines.
Our system provides the ability to query for assets at a location. This can be used
to query for inventory in a supply room or even to identify which patient rooms are
assigned. Providing a common asset/inventory system for a healthcare facility is one step
31
in simplifying the kinds of software in healthcare as a typical hospital has many stovepipe
asset management systems and often these systems do not interoperate well.
Our system could reduce the loss of equipment, supplies and avatars in the
hospital by using the tracking query which will tell hospital personnel all of the places a
certain item has been too. This could be used to track how people spend their time or
equipment usage or to watch over babies in a nursery or Alzheimer patients.
Finally, we identified some complications to our simple supply chain model
which would make the model more realistic.
5.3 Future Work
This research can be extended in several ways.
As described in Chapter 4, our current supply chain model is simplistic (purposely
so). In that chapter, we identified a number of real-world extensions that would be
needed for modeling more realistic supply chains, Developing a more comprehensive
supply chain model is future work, complicated by the likelihood that different
organizations might model some, all, or additional issues much differently, one from
another.
As mentioned in Chapter 1, the recently available open source server for Second
Life (OpenSim) provides an internal relational DBMS, and this DBMS is accessible to
developers. Implementing our basic and complex queries in this DBMS and extending it
to cover workflow tasks is an interesting future direction. An interesting issue to explore
is whether we should extend the core system’s DBMS to model application logic related
to supply chains or keep the system’s DBMS separate from any application DBMS.
32
We could make our hospital a model for emerging GS1 global healthcare and
electronic patient record standards. One step in this direction would be to use GS1 Global
Trade Item Numbers (GTIN) to refer to all medical items.
In the direction of more pervasive computing, we could record even more about
Second Life than we presently do. For instance, we could record SL notecards or chat. We
could record every workflow task and subtask within the hospital. We could record the entire
supply chain of goods before they enter the hospital. We could keep the entire history of all
logged items in the database, never deleting any history. This could give us full visibility of
the entire present and past in a SL world. In separate work, PhD student Josh Eno at the
University of Arkansas is developing a search engine for virtual worlds that explores these
and other questions.
We could analyze the historical record looking for “interesting” events – e.g., when a
patient did not receive treatment as quickly as needed – to try to understand the root cause.
We could consider various configurations for where to place RFID readers or supply rooms
(should there be one central one, satellite rooms, or should supplies be distributed) and then
run simulations, record all results and analyze these to understand tradeoffs. We might
explore parsing observed events to recognize higher level workflows.
We could consider how the DBMS system hooks up to Second Life and how to
improve the hook up to better match reality. In our present system, we use just one DBMS
to store all records – this includes all items in the supply chain even if owned by different
organizations. It would make sense that these items would be in separate DBMS systems,
managed by their parent organizations. If we hooked up several DBMS systems, our queries
to discover the history of an object as it passed through the supply chain must now become
distributed queries to separately owned DBMS systems. We could assume all these DBMS
systems represented their data similarly. More realistically, we could assume they all used
33
their own heterogeneous representations. There is still a need for such queries but then we
could study the standards that would be needed to enable cross-DBMS queries.
34
REFERENCES
[1]
C. Thompson, “Everything is Alive,” Architectural Perspective Column, IEEE
Internet Computing, January-February 2004.
http://vw.ddns.uark.edu/content/2004-01--PAPER--IEEE-Internet-Computing-Everything-is-Alive.pdf
[2]
R. Harris, “Future Tech, Security & Public Policy, MyLifeBits, NIMD, NSA and
You. Or Rather, Us.” referenced: May 24, 2006,
http://storagemojo.com/2006/05/24/mylifebits-nimd-and-you-or-rather-us
[3]
M. Myser, “In 2021 You'll Enjoy Total Recall”, referenced: May 17, 2006.
http://www.popsci.com/scitech/article/2006-05/2021-youll-enjoy-total-recall
[4]
A. Belasco, “Total Information Awareness Programs,” referenced: March 21,
2003. http://usacm.acm.org/usacm/PDF/CRSTIAReport.pdf
[5]
“Technological Singularity”, Wikipedia, referenced: October 11, 2008.
http://en.wikipedia.org/wiki/Technological_singularity
[6]
“Second Life”, Wikipedia, referenced: October 10, 2008.
http://en.wikipedia.org/wiki/Second_Life
[7]
“Supply chain”, Wikipedia, referenced: March 9, 2009.
http://en.wikipedia.org/wiki/Supply_chain
[8]
Bill C. Hardgrave, “Does RFID Improve Inventory Accuracy? A Preliminary
Analysis”, Technical Report, RFID Center, Information Technology Research
Institute, http://itri.uark.edu/104.asp?code=rfid&article=ITRI-WP107-0311
[9]
High Level Architecture, Wikipedia, referenced: April 26, 2009.
http://en.wikipedia.org/wiki/IEEE_1516
[10]
K. Pehlivanis, M. Papagianni, A. Styliadis, “Virtual Reality & Logistics,”
Proceedings of the International Conference on Theory and Applications of
Mathematics and Informatics (ICTAMI), Thessaloniki, Greece, 2004, p. 377-384
[11]
C. Bailey, “Extending Second Life Simulations with Virtual RFID,” BS Honors
Thesis, Computer Science and Computer Engineering Department, University of
Arkansas, Spring 2008.
[12]
Ann Myers Medical Center, http://ammc.wordpress.com/
35
[13]
Health Info Island, http://healthinfoisland.blogspot.com/
[14]
Second Health, http://secondhealth.wordpress.com/
[15]
UC Davis Virtual Hallucinations,
http://www.ucdmc.ucdavis.edu/ais/virtualhallucinations/
[16]
Cisco and Palomar Pomerado Health,
http://newsroom.cisco.com/dlls/2008/prod_022508d.html
[17]
J. Hoag, C. Thompson, “Architecting RFID Middleware,” Architectural
Perspectives column, IEEE Internet Computing, September-October 2006.
http://vw.ddns.uark.edu/content/2006-09--PAPER--IEEE-Internet-Computing-Architecting-RFID-Middleware.pdf
36
APPENDIX A
This appendix consists of two sections, the first section shows the PHP code for
the simple database engine that was implemented. The second section shows the code
behind the Second life engine.
Appendix A.1
Below is the PHP code for the database engine mentioned is Section 4.1. As
mentioned in the section, this code consists of several functions that will execute a certain
query depending on the parameter that it receives from Second Life.
<?php
// Database Settings
include "../db_config.php";
switch(strtoupper($_REQUEST['command'])){
case 'ADDENT':
cmd_addent($_REQUEST);
break;
case 'GETENT':
cmd_getent($_REQUEST);
break;
case 'ADDAST':
cmd_addast($_REQUEST);
break;
case 'UPDAST':
break;
case 'GETAST':
cmd_getast($_REQUEST);
break;
case 'DELENT':
cmd_delent($_REQUEST);
break;
default:
echo ("Invalid Command Requested");
}
exit;
/* Database functions below */
function cmd_addent($params){
// Check for required parameters
$req = array('id','desc','type');
foreach($req as $rkey){
$rkey = mysql_real_escape_string($params[$rkey]);
}
//create and execute the query
37
$sql = "INSERT INTO entity (entityID, description,
entity_type) VALUES ('$id', '$desc', '$type')";
$result = mysql_query($sql) or die(mysql_error());
echo 'Add entity successful!';
}
function cmd_getent($params){
// Check for required parameters
$id = mysql_real_escape_string($params['id']);
//create and execute the query
$sql = "SELECT * FROM entity WHERE entityID = '$id'";
//$result = mysql_query($sql) or die(mysql_error());
$result = mysql_db_query ($dbname, $sql);
if (mysql_num_rows($result) == 0) {
echo "Specified entity not found!";
exit;
}
//return the results
while($row = mysql_fetch_assoc($result)) {
$sepr = "";
foreach ($row as $value) {
echo $sepr . $value;
$sepr = "||";
}
echo "\n";
}
}
function cmd_addast($params){
// Check for required parameters
$req = array('eid', 'aid', 'rcode','lcode', 'qty');
foreach($req as $rkey){
$$rkey = mysql_real_escape_string($params[$rkey]);
}
//create and execute the query
$sql = "INSERT INTO asset (assetID, entityID, region_code,
location_code";
if ($qty >= 0) $sql .= ", quantity";
$sql .= ") VALUES ('$aid', '$eid', '$rcode', '$lcode'";
if ($qty >= 0) $sql .= ", '$qty'";
$sql .= ")";
$result = mysql_query($sql) or die(mysql_error());
echo 'Add asset successful!';
}
function cmd_delent($params){
// Check for required parameters
$id = mysql_real_escape_string($params['id']);
//create and execute the query
$sql = "update entity set Delete_Flag='I' WHERE entityID =
'$id'";
$result = mysql_query($sql) or die(mysql_error());
if (mysql_num_rows ($result) ==0) {
echo "Specified entity not found!";
}else{ echo "Done!";} //1099254 delent||3
}
38
function cmd_getast($params){
// Check for required parameters
$aid = mysql_real_escape_string($params['aid']);
//create and execute the query
$sql = "SELECT * FROM asset WHERE assetID = '$aid'";
$result = mysql_query($sql) or die(mysql_error());
if (mysql_num_rows($result) == 0) {
echo "Specified entity not found!";
exit;
}
//return the results
while($row = mysql_fetch_assoc($result)) {
$sepr = "";
foreach ($row as $value) {
echo $sepr . $value;
$sepr = "||";
}
echo "\n";
}
}
?>
39
Appendix A.2
The following code was written in Second life scripting language LSL to create a
connection between Second Life and real life. A few functions were written here to
execute several queries. More details about the use of this function in Section 4.1.
//Communicates with php scripts on server
//string URL1="http://130.184.104.29/SL/test.php";
//string URL2="http://130.184.104.29/SL/entity_asset.php";
string URL1="http://comp.uark.edu/~ksp03/test.php";
string URL2="http://comp.uark.edu/~ksp03/entity_asset.php";
string URL3="http://comp.uark.edu/~ksp03/patient.php";
string URL4="http://comp.uark.edu/~ksp03/ea_queries.php";
list post_cmd = [HTTP_METHOD, "POST", HTTP_MIMETYPE,
"application/x-www-form-urlencoded"];
key http; //This stores the HTTP request we send.
integer listen_handle;
default
{
state_entry() {
listen_handle = llListen(1099254, "", NULL_KEY, "");
}
touch_start(integer foo)
{
http=llHTTPRequest(URL1, post_cmd, "parameter1=" +
(string) llDetectedKey(0) +
"&parameter2=" +
llDetectedName(0));
}
http_response(key id,integer status, list meta, string body)
{
if(http==id)
{
integer i;
list lbody=llParseString2List(body,["\n"],[]);
integer count=llGetListLength(lbody);
for(i=0;i<count;i++)
{
llWhisper(0, llList2String(lbody,i));
}
}
}
listen(integer channel, string name, key id, string message) {
list params;
string cmd;
string tmp;
string extra = "";
40
list pfields = ["cmd", "pid", "desc", "region", "location",
"reason", "temper", "pulse", "resp", "bp"];
list afields = ["cmd", "aid", "eid", "expire", "region",
"qty"];
integer xx;
integer flag = FALSE;
if(channel==1099254) {
params = llParseStringKeepNulls(message, ["||"], []);
cmd = llList2String(params, 0);
if(cmd == "addent") {
http=llHTTPRequest(URL2, post_cmd,"command=" + cmd +
"&id=" + llList2String(params, 1) + "&desc=" +
llList2String(params, 2) + "&type=" +
llList2String(params, 3));
} else if (cmd == "getent") {
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd +
"&id=" + llList2String(params, 1));
} else if (cmd == "addast") {
http=llHTTPRequest(URL2,
post_cmd, "command=" + cmd +
"&eid=" +
llList2String(params, 1) +
"&aid=" +
llList2String(params, 2) +
"&rcode=" +
llList2String(params, 3) +
"&lcode=" +
llList2String(params, 4) +
"&qty=" +
llList2String(params, 5));
} else if (cmd == "getast") {
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd + "&aid="
+ llList2String(params, 1));
} else if (cmd == "updast") {
tmp = llList2String(params, 1);
if (tmp != "") extra = "&aid=" + tmp;
for (xx = 2; xx < 6; xx++) {
tmp = llList2String(params, xx);
if (tmp != "") {
extra += "&" + llList2String(afields, xx)
+ "=" + tmp;
flag = TRUE;
}
}
if (flag) {
extra = "command=" + cmd + extra;
http=llHTTPRequest(URL2, post_cmd, extra);
}
} else if (cmd == "delent") {
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd + "&id="
+ llList2String(params, 1));
} else if (cmd == "chkrole") {
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd +
"&aid=" + llList2String(params, 1) + "&role=" +
llList2String(params, 2));
} else if (cmd == "addrole") {
41
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd +
"&aid=" + llList2String(params, 1) + "&role=" +
llList2String(params, 2));
} else if (cmd == "delrole") {
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd +
"&aid=" + llList2String(params, 1) + "&role=" +
llList2String(params, 2));
} else if (cmd == "existspatient") {
http=llHTTPRequest(URL3, post_cmd, "command=" + cmd +
"&pid=" + llList2String(params, 1));
} else if (cmd == "addpatient") {
for (xx = 1; xx < 5; xx++) {
extra += "&" + llList2String(pfields, xx) + "=" +
llList2String(params, xx);
}
for (xx = 5; xx < 10; xx++) {
tmp = llList2String(params, xx);
if (tmp != "")
extra += "&" + llList2String(pfields, xx) + "=" + tmp;
}
extra = "command=" + cmd + extra;
http=llHTTPRequest(URL3, post_cmd, extra);
} else if (cmd == "updpatient") {
tmp = llList2String(params, 1);
if (tmp != "") extra = "&pid=" + tmp;
for (xx = 2; xx < 10; xx++) {
tmp = llList2String(params, xx);
if (tmp != "") {
extra += "&" + llList2String(pfields, xx)
+ "=" + tmp;
flag = TRUE;
}
}
if (flag) {
extra = "command=" + cmd + extra;
http=llHTTPRequest(URL3, post_cmd, extra);
}
} else if (cmd == "getpatient") {
http=llHTTPRequest(URL3, post_cmd, "command=" + cmd + "&pid=" +
llList2String(params, 1) + "&histcnt=" +
llList2String(params, 2));
} else if (cmd == "updlocation") {
http=llHTTPRequest(URL3, post_cmd, "command=" + cmd +
"&pid=" + llList2String(params, 1) + "&location=" +
llList2String(params, 2));
} else if (cmd == "comprole") {
http=llHTTPRequest(URL4, post_cmd, "command=" + cmd +
"&avatarid=" + llList2String(params, 1) + "&objectid=" +
llList2String(params, 2));
} else if (cmd == "objectsat") {
http=llHTTPRequest(URL4, post_cmd, "command=" + cmd +
"&desc=" + llList2String(params, 1) + "&locations=" +
llList2String(params, 2));
} else if (cmd == "avatarat") {
tmp = llList2String(params, 1);
if (tmp != "") {
extra = "&avatarid=" + tmp;
42
} else {
extra = "&avatarname=" + llList2String(params, 2);
}
http=llHTTPRequest(URL4, post_cmd, "command=" + cmd + extra);
} else if (cmd == "avatarsattime") {
http=llHTTPRequest(URL4, post_cmd, "command=" + cmd +
"&cutoff=" + llList2String(params, 1) + "&locations=" +
llList2String(params, 2));
} else {
http=llHTTPRequest(URL1, post_cmd, "parameter1=" + name +
"&parameter2=" + message);
}
}
}
}
43
APPENDIX B
This Appendix shows the functions that were build to develop the tracking system
and the code behind the sensors(s).
Appendix B.1
This is the PHP code that is used to execute the three main queries in Second Life,
where is, List and track. The code will execute three queries depending on the parameter
that we send to it.
<?php
// Database Settings
require "db_config.php";
switch(strtoupper($_REQUEST['command'])){
case 'WHERE IS':
cmd_where_is($_REQUEST);
break;
case 'TRACK':
cmd_track($_REQUEST);
break;
case 'LIST OBJECTS IN':
cmd_list_objects($_REQUEST);
break;
default:
echo ("Invalid Command Requested" . $_REQUEST['command']);
}
//close the database connection
mysql_close($link);
//stop execution
exit;
function cmd_where_is($params){
// Check for required parameters
$id = mysql_real_escape_string($params['id']);
//create and execute the query
$sql = "SELECT * FROM Location WHERE Key_ID = '$id' and
End_Date is null or End_Date in (SELECT max(End_Date) FROM
Location where Key_ID='$id') ";
$result = mysql_query($sql) or die(mysql_error());
if (mysql_num_rows($result) == 0) {
echo "Specified entity not found!";
exit;
}
44
$row = mysql_fetch_assoc($result);
echo $row['Name'] . "\n is in " .
on " . $row['Start_Date'];
$row['Region'] .
"\n
}
function cmd_track($params){
// Check for required parameters
$id = mysql_real_escape_string($params['id']);
//create and execute the query
$sql = "SELECT * FROM Location WHERE Key_ID = '$id' order
by ID";
$result = mysql_query($sql) or die(mysql_error());
if (mysql_num_rows($result) == 0) {
echo "Specified entity not found!";
exit;
}
$row = mysql_fetch_assoc($result);
echo $row['Name'] . "\n History is: \n";
//return the results
while($row = mysql_fetch_assoc($result)) {
//$sepr = "";
echo $row['Start_Date'] . " " . $row['Region']. "\n";
}
}
/**/
function cmd_list_objects($params){
// Check for required parameters
$region = mysql_real_escape_string($params['region']);
//create and execute the query
$sql = "SELECT * FROM Location WHERE Region = '$region' and
(End_Date ='0000-00-00 00:00:00' or
End_Date in (SELECT max(End_Date) FROM Location
group by Name))";
$result = mysql_query($sql) or die(mysql_error());
if (mysql_num_rows($result) == 0) {
echo "No items are found in $region";
exit;
}
$row = mysql_fetch_assoc($result);
while($row = mysql_fetch_assoc($result)) {
echo $row['Name'] .
"\n";
}
?>
45
Appendix B.2
This is the code behind the sensor(s) in Second Life. When it runs it will set the
alpha to zero so that the object will become invisible. Then it will run every time a
collision happens and ends as soon as the collision terminates. When a collision happens
it calls a PHP function to insert a row into the location table. When a collision ends it
send another call to update the entry in the location table. More details about the sensors
and the way they work is mentioned in section 3.3
string last_visitor = "";
default
{
state_entry()
{
llSetAlpha(0,ALL_SIDES);
llVolumeDetect(TRUE);
llSetText( "I am here.", < 1, 0, 0 >, 1 );
}
collision_start(integer num)
{
integer i;
for (i = 0; i < num; i++)
{
string name = llDetectedName(i);
if (name != last_visitor)
{
string url = "
http://comp.uark.edu/~ksp03/get_data.php?";
url += "name=" + llEscapeURL(name);
url +=
"&key="llEscapeURL((string)llDetectedKey(i));
url += "&object=" +
llEscapeURL(llGetObjectName());
llHTTPRequest(url ,[HTTP_METHOD,"GET"],"");
last_visitor = name;
}
}
}
}
46
APPENDIX C
This is the code behind the Second Life engine that will execute the three main
queries that we built the PHP code for in Appendix B.1. This function will take the user
input and convert it into a Second Life post command then send it to the PHP function
with the parameters. After that the PHP code will return the results for this function.
//Communicates with php scripts on server.
//Using this script you can insert a record to a table in a MySql
Database,
// Query the DB, and Delete a record from the DB.
URL2="http://130.184.104.29/sldbaccess/location.php";
list post_cmd = [HTTP_METHOD, "POST", HTTP_MIMETYPE,
"application/x-www-form-urlencoded"];
key http; //This stores the HTTP request we send.
integer listen_handle;
integer linePos = 0;
list lines;
integer listLength;
vector textColor = <0,1,0>; // Green
updateDisplay()
{
string output;
integer i;
integer count = listLength;
for (i = 0; i < count; i++)
{
output += llList2String(lines, i);
}
llSetText(output, textColor, 1.0);
//addLine("output0 is " + output);
}
default
{
state_entry() {
llSetText(" ", <0,0,0>, 1.0);
//listen_handle = llListen(1099254, "", NULL_KEY, "");
listen_handle = llListen(109, "", NULL_KEY, "");
}
touch_start(integer foo) {
if (llDetectedKey(0) == llGetOwner()) {
string output;
integer i;
integer count = listLength;
for (i = 0; i < count; i++) {
output = llList2String(lines, i) + "\n";
47
}
llSetText(output, textColor, 1.0);
//addLine("output" + output);
} else llSetText("", ZERO_VECTOR, 0.0);
//http=llHTTPRequest(URL1, post_cmd,
//"parameter1=" + llDetectedName(0) +
"&parameter2=Hello, Object!");
}
http_response(key id,integer status, list meta, string body)
{
if(http==id)
{
//integer i;
//list lbody=llParseString2List(body,["\n"],[]);
//integer count=llGetListLength(lbody);
//This turns newline characters char(10) into new
lines in chat
//These are Unix/LSL style end of lines, use \r\n in
place of \n for
//Windows style end of line from web server.
//for(i=0;i<count;i++)
//{
//addLine(llList2String(lbody,i));
//}
llSay(1001,body);
llSetText(body, textColor, 1.0);
}
}
listen(integer channel, string name, key id, string
message) {
list params;
string cmd;
if(channel==109) {
params = llParseString2List(message, ["||"], []);
cmd = llList2String(params, 0);
if(cmd == "where is") {
http=llHTTPRequest(URL2, post_cmd,"command=" + cmd +
"&id=" + llList2String(params, 1));
} else if (cmd == "track") {
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd +
"&id=" + llList2String(params, 1));
} else if (cmd == "list objects in") {
http=llHTTPRequest(URL2, post_cmd, "command=" + cmd +
"&region=" + llList2String(params, 1));
} else {
}
}
}
}
48