On Integrating Physical Objects with the Internet
Niranjan Kundapur Bachelor of Technology, Mechanical Engineering (1998) Indian Institute of Technology, Madras
Submitted to the Department of Mechanical Engineering in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY
September 2000
© Massachusetts Institute of Technology, 2000. All Rights Reserved.
Author ...... Department of Mechanical Engineering June 30, 2000
Certified by ...... Professor Kai-Yeung 'Sunny' Siu Associate Professor of Mechanical Engineering Thesis Supervisor
C ertified by ...... 7 ...... Professor Sanjay E Sarma Associate Professor of Mechanical Engineering Thesis Supervisor
A ccepted by ...... Professor Am A Sonin Chairman, Department Committee on Graduate Students MASSACHUSETTS INSTITUTE OF TECHNOLOGY
SFP 2 0 7000
LIBRARIES BARKER M.I.T. LIBRARIES - BARKER 2 On Integrating Physical Objects with the Internet
by Niranjan Kundapur
Submitted to the Department of Mechanical Engineering on June 30, 2000 in partial fulfillment of the requirements for the degree of Master of Science
Abstract
This thesis examines key areas of research involved in integrating information, which pertains to physical objects, with the Internet, and delivering this information anytime anywhere. We broadly classify the research areas into three layers: the Physical Object Layer, the Information Storage Layer, and the Wide Area Access Layer. We discuss background information relevant to each of the layers, such as Universal Product Code (UPC), JiniTM, Bluetooth, eXtensible Markup Lan- guage (XML), XML Query Language (XQL), Wireless Application Protocol (WAP), and Wireless Markup Language (WML).
The Electronic Product Code (ePC), which was developed by David Brock of MIT, is a unique identification number for each physical object. It serves as a numerical reference to information, which pertains to a physical object, on the Internet. This number is embedded in radio frequency (RF) Tags attached to an object. An RF Tag Reader can read the embedded ePC when the Tag is within a certain distance of the Reader. In the Physical Object Layer, our work describes how the ePC complements Resource Discovery protocols, such as JiniTM and Bluetooth, in Local Area Net- works of Devices, such as RF Tag Readers. Since information regarding the movement of physical objects is critical in many applications, we propose the RSVP protocol among RF Tag Readers, to track tagged physical objects. We also compare the different numbering schemes of the ePC.
The information, which is referenced by the ePC of a physical object, is in Physical Markup Lan- guage (PML) format. This format serves as the lingua franca for describing physical objects. In the Information Storage Layer, we develop insight into the data model of XML. Since PML is based on XML, this insight will be useful during the ongoing research to define PML. We discuss issues of implementation of the data model and issues of cooperation in the choice of PML elements. Our implementation work in this layer is the use of XML and XQL along with JiniTM to develop a cli- ent-server software application, which tracks physical objects moving in a remote location.
The Wide Area Access Layer comprises various application platforms that deliver information on physical objects to mobile users. We describe our application that allows a user to access, using her WAP-enabled cell phone, data from remote sensors. We describe our software application, which automatically converts PML to WML format for display on mobile devices.
Thesis Supervisor: Kai-Yeung 'Sunny' Siu Title: Associate Professor
Thesis Supervisor: Sanjay E Sarma Title: Associate Professor
Acknowledgement
I thank Prof. Sanjay Sarrna for introducing me to the Auto-ID Center. I also thank him for his general advice and friendliness. I am grateful to Joe Foley and Jocelyn 'Bink' Tait for giving me valuable suggestions during my research. Thanks to Bink for suggesting significant improvements while proof-reading my thesis. Thanks to Joe Foley and Aparna Chennapragada for proof-reading parts of my thesis. Thanks to Yogesh Joshi for being a pal at the lab. Thanks to David Rodriguera for his help in taking care of my administrative work. Thanks to Mahadevan Balasubramaniam, Elmer Lee, Stephen Ho. Paula Valdivia y Alvarado, and Edmund Golaski of Rapid Autonomous Machining Laboratory for advice and the good times. Thanks to the Pakodas for making life at Cambridge a lot of fun. Thanks to Jeff Vanness, Michael Padilla, and Dave Steare, all of whom made my first year at MIT's Tang Hall memorable. Thanks to Trupti, Amma, Annu, and Shweta for love and support.
Niranjan Kundapur
5 6 Table of Contents
Chapter 1: Introduction ------11 1.1 Organization of Subsequent Chapters ------12 Chapter 2 : Physical Object Layer ------17 2.1 The ePC as the Future Product Identification Code ------17 2.1.1 The Current Bar Code ------17 2.1.2 The ePC in Comparison with the UPC bar code ------18 2.2 The ePC as Device ID: Local Area Networking of Physical Objects ------21 2.2.1 Resource Discovery: JiniTM ------21 2.2.2 Bluetooth ------22 2.3 The RSVP Proposal ------22 2.3.1 The Problem ------22 2.3.2 A Solution in the Style of TCP ------22 2.3.3 Assumptions ------23 2.3.4 Sender Function ------24 2.3.5 Receiver Function ------24 2.3.6 Boundary Conditions ------25 2.3.7 Data-structures and Algorithms ------25 2.3.8 Solution of the Original Problem------25 Chapter 3 : Information Storage and Retrieval Layer ------27 3.1 eXtensible Markup Language ------27 3.1.1 XML in Brief ------28 3.2 XML data format ------29 3.2.1 Data, Meta-Data, Relationships, and Documents ------29 3.2.2 Data Models ------31 3.2.3 Creating XML documents from Entity-Relationship data model ------33 3.2.4 Logical Structure of XML ------36 3.2.5 XML Text Parsers ------37 3.2.6 Implementation Structure in XML ------37 3.2.7 Practical Issue of Collaboration ------39 3.2.8 Final Remarks on XML ------39 3.2.9 Other Members of XML Family ------40 3.2.10 XQL ------41 3.3 PMLandONS ------42 3.4 Applications: Inventory Tracking Software Module ------43 Chapter 4 : Wide Area Access Layer ------45 4.1 Technologies Used ------45 4.1.1 Wireless Application Protocol ------45 4.1.2 Wireless Markup Language ------46 4.1.3 WMLScript Language ------47
7 4.2 Design by Synthesis of Technologies ------48 4.2.1 PML-to-WML Conversion ------48 4.2.2 Server and Servlets ------50 4.2.3 BASIC Stamp and DS1620 ------50 4.2.4 WAP Gateway ------51 4.3 Lessons Learned and Applications ------52 Chapter 5 : Conclusions ------55 Appendix A: Acronyms ------57 Appendix B : Generations of Database Systems ------59 Appendix C: Use of XML/XQL ------61 Appendix D : ServIet program ------63 References ------65
8 List of Figures
Figure 1.I: Logical Layers of Abstraction of Research ------13 Figure 2.1: RSVP Proposal ------23 Figure 3.1: Tree structure of the environment of physical objects ------27 Figure 3.2: Data, information, and knowledge ------28 Figure 3.3: Integrating data into document-centric documents ------31 Figure 3.4: Levels of data abstraction and Migration of complexity ------31 Figure 3.5: E-R semantic data model to construct a bank schema ------33 Figure 3.6: Relational data model of bank schema ------33 Figure 3.7: Object-oriented data model of bank schema------34 Figure 3.8: XML text file to represent the E-R data model ------34 Figure 3.9: Object-oriented data model of bank schema, with inheritance ------35 Figure 3.10: XML text file to represent the inheritance ------35 Figure 3.11: XML file ------36 Figure 3.12: DOM representation of the XML file in Figure 3.11 ------36 Figure 4.1: WAP Architecture------46 Figure 4.2: Overview of System ------48 Figure 4.3: PML to WML mapping ------49 Figure 4.4: Nokia cell phone emulator displaying Tide.wml------49 Figure 4.5: BASIC Stamp I------51 Figure 4.6: Circuit diagram: BASIC Stamp and DS1620 ------52 Figure D.1: Directory structure of server------63 List of Tables
Table 2.1: Old bar-codes and New bar-codes ------18 Table 2.2: UPC bar code vs. ePC embedded in RF Tags: Implementation Issues ------19 Table 2.3: Numbering scheme of ePCs ------20 Table 3.1: Data-centric and Document-centric Documents------30 Table 3.2: XML-text-to-DOM Parser vs. SAX Parser ------38
10 Chapter 1: Introduction
The Internet has made available a variety of multimedia information practically anytime any- where. The wireless Internet will be able to provide such information even to mobile users in the coming years. One of the most important networks is the network of physical objects. The Auto-ID Center of MIT is exploring methods and infrastructure, which can deliver pertinent information on physical objects anytime anywhere [1]. A glut of data on a physical object can be delivered to an entity that requests information. In a given situation, only a portion of this data will be pertinent. The problem of automatically determining what data is relevant to a particular situation is a very challenging one. With the advent of new business paradigms, such as e-commerce, the speed of response in supply networks is becoming increasingly inadequate. Traditional commercial functions, such as price comparisons and order placements of products, are being done online. If products are not available in stock, then potential customers can change their choice with a few mouse clicks. Therefore, distribution networks need to respond rapidly to demand. Lifestyles of people have become more information-oriented; people are also busier than before [2]. Therefore, there is a necessity for high-speed networks and automation in homes. The need for appliances, which are connected to the Internet, and which require minimum effort to set up for operation, is greater. Various applications, including quick-response supply networks, 'smart' homes, and auto- matic configuration of devices, will be facilitated if physical objects and their characteristics can be automatically identified.
The Auto-ID Center evolved out of the Distributed Intelligent Systems Center (DISC) [3] of MIT. The aim of the Auto-ID Center is to create an open and scalable architecture for embedding automatic identification technology in physical objects in order to provide access to information on them. The technologies developed by the Auto-ID Center are the Electronic Product Code (ePC), the Object Naming System (ONS), and the Physical Markup Language (PML). In addition, the Center encourages, uses, and applies communication standards, such as the Wireless Applica- tion Protocol (WAP) [4], and data-exchange standards, such as the eXtensible Markup Language (XML) [5]. These standards are being used to specify how physical objects should communicate information about themselves to sensors, which in turn communicate with sophisticated computa- tional tools and the Internet. Some of these standards are also being used to specify how to access and display this information. Previous systems to identify physical objects, specifically products for retail and items in tran- sit, include the Universal Product Code (UPC) system [6]. The UPC system, also known as the bar code system, was the result of efforts by the Uniform Code Council (UCC), Inc. which is a sponsor of the Auto-ID Center.
This thesis examines key areas in integrating information, which pertains to physical objects, with the Internet and attempts to provide a framework for continuing research in this exciting field.
11 1.1 Organization of Subsequent Chapters
We broadly classify our research into three logical layers of abstraction, which are: 1. the Physical Object Layer 2. the Information Storage and Retrieval Layer 3. the Wide Area Access Layer These layers are illustrated in Figure 1.1. Each layer is described in an individual chapter.
For the purpose of clarity, we differentiate between two types of physical objects based on their behavior: 1. Individual Inventory Item, which is a physical object in an inventory or in transit. While a Stock Keeping Unit (SKU) represents a product group, Individual Inventory Item rep- resents an individual item of the SKU group. 2. Device, which is a sensor or an actuator. The same physical object may exhibit both the behaviors. For example, an RF Reader in a retail store or in transit behaves like an Individual Inventory Item. The same Reader in a Local Area Network (LAN) behaves like a Device.
Physical Object Layer
The Physical Object Layer is discussed in Chapter 2. It comprises the ePC, which was devel- oped by David Brock [7] of MIT. It is a unique 128-bit identification number for physical objects. The fact that the ePC can uniquely identify every molecule on this planet gives us an idea of how well it scales with any increase of the number of physical objects, which need to be uniquely iden- tified. The ePC of a physical object serves as a reference to information, which pertains to the object, on the Internet. We compare the advantages and disadvantages of the different numbering schemes of the ePC.
In this chapter, we discuss background information on the UPC bar code and the ePC -- how they are similar in concept and how they are different in implementation. The current UPC bar code is reaching its capacity and will not be useful in the future [1]. One of the ways of implement- ing the ePC of an Individual Inventory Item is by embedding the 128 bits in the chip of a Radio Frequency (RF) Tag, which is attached to the physical object. An RF Tag Reader can detect a Tag when the Tag is within a certain distance of the Reader. If the ePC is embedded in the Tag, then the Reader can also read the ePC. Therefore, in the future, the ePC can be used as the identification code for an Individual Inventory Item. The RF interaction between a Tag and a Reader is schemat- ically represented by the dotted concentric circles in Figure 1.1. It is important to note that the ePC can be implemented in various ways and that RF Tags is just one of the ways.
The ePC of a Device is implemented in a chip, which can be accessed by entities that control the operation of the Device. The Device may also have its ePC embedded in the chip of an RF Tag. Each Device, which is assembled in a Local Area Network (LAN), can be uniquely identified by its ePC. The other members of the network will use this identification number to communicate with the Device. In such networks, spontaneous discovery of new Devices in a LAN is a useful
12 WIDE AREA ACCESS LAYER
INFORMATION STORAGE AND Mobile RETRIEVAL LAYER Access
type3 -- - Desktop
flAfT r1v1L~e1~ Access I7EVILnKiv L-J-_aL PMLV Ser ver / database / Access ePC-PML Server fype 2 etc... by servers, mapping appliances, etc.
ONS on the Internet / type I
_ I / PHYSICAL OBJEC T LAYER
Individual Inventory Item (Physical Object)
LAN of RF Reader Devices (Physical Objects) -PC embedded in RF Tag
Figure 1.1: Logical Layers of Abstraction of Research feature because it facilitates immediate and automatic determination of the functions of the Device. This is also known as Resource Discovery, and Plug and Play. We discuss background information on technologies for Resource Discovery, such as JiniTh [8] and Bluetooth [9], in LANs of Devices, such as RF Tag Readers. In this chapter, we show how Resource Discovery pro- tocols and the ePC complement each other. In Figure 1.1, the solid lines, which represent the LAN, may correspond to a wireless or a wired LAN.
Important questions concerning an Individual Inventory Item include its current location, its history of movements, and its predicted movements in the future. As pointed out earlier, an RF Tag Reader can detect a Tag (and read its ePC) when the Tag is located within the operational range of
13 the Reader. Since an Individual Inventory Item will be tagged with an RF Tag, its location can be determined by RF Tag Readers when they detect the Tag. The RF Readers, which are Devices, will be identified with an ePC and assembled in a LAN subscribing to the JiniTM or Bluetooth protocol. We propose the RSVP protocol among RF Tag Readers for tracking tagged Individual Inventory Items. Important application of this proposed protocol are detection of theft in progress in a retail store, and inventory tracking in a warehouse.
Information Storage and Retrieval Layer
The Information Storage and Retrieval Layer is discussed in Chapter 3. It comprises PML and ONS. As pointed out earlier, the ePC serves as a reference to information, which pertains to a physical object, on the Internet. This information is stored in the form of a PML file in a remote PML Server. PML serves as the lingua franca for describing physical objects. The ONS maps the ePC of a physical object to a PML Server, on which the object's PML file is located. Whenever an entity requires information on a physical object, it queries the ONS by passing to it the ePC of the object. The ONS returns to the requesting entity the Internet Protocol (IP) address of the PML Server. The requesting entity can then download pertinent information on the physical object by querying the PML Server. The PML Server satisfies the request for information by sending the PML file, or a pertinent portion of it.
In this chapter, we discuss background information on XML, and investigated the implications of the XML data model. Our insight will be useful during the work required to define PML. We discuss XML as not only a markup language, which it was originally, but also a data exchange for- mat and a data model. To make XML useful in its current role as a data exchange format and a data model, an entire family of technologies is being designed by the Worldwide Web Consortium (W3C) [5]. We discuss background information on the XML family, which includes a query lan- guage and a style sheet language. In this chapter, we present our insight into the data model of XML, issues of implementation of the data model, and issues of collaboration in the choice of PML elements. Our practical work in this layer involves the use of XML and XML Query Lan- guage (XQL) [10], along with JiniTM, to develop a client-server software application that tracks physical objects moving in a remote location.
Wide Area Access Layer
The Wide Area Access Layer is described in Chapter 4. The previous two layers, the Physical Object Layer and the Information Storage and Retrieval Layer, deal with issues involved in net- working physical objects among themselves and with the Internet, and storing and retrieving infor- mation about physical objects. The Wide Area Access Layer comprises various application platforms that will deliver and display this information to mobile users. These application plat- forms include desktop computers, cell phones, and other appliances.
To demonstrate that it is possible to deliver information on physical objects anytime anywhere, we developed an application that allows a mobile user to access, on her cell phone, data from remote Devices. The mobile user can identify the particular remote Device, from which it wants information, by the Device's ePC. The Device we used in our implementation was a simple tem- perature sensor connected to a Web Server. The Device could just as well have been the controlling
14 computer of a LAN of RF Readers, a motor which could close a gate, or a switch. This is schemat- ically represented by type I in Figure 1.1. If the ePC of a physical object is known by the user, then it is possible to query the ONS for information on the physical object using any of the application platforms, including a cell phone. This is schematically represented by type 2 in Figure 1.1. A cell phone can also be used to request PML information from the PML Server directly. This is schematically represented by type 3 in Figure 1.1.
We discuss background information on technologies, such as WAP, Wireless Markup Lan- guage (WML), and WML Script Language. In this chapter, we describe our implementation by the synthesis of the above technologies, Java servlets, and a BASIC Stamp. This chapter also describes our software for conversion of PML data to WML. This will be useful when a cell phone user requests PML information directly from the PML Server.
15 16 Chapter 2: Physical Object Layer
In Section 2.1 of this chapter, we present background information on the current UPC bar code and the ePC -- how they are similar in concept and how they are different in implementation. We compare the advantages and disadvantages of the different numbering schemes of the ePC. We present background information on technologies for Resource Discovery, such as JiniTM and Bluetooth in Section 2.2. We show how the ePC complements Resource Discovery protocols. In Section 2.3, we describe our proposed RSVP protocol for tracking tagged physical objects in a sensor environment.
2.1 The ePC as the Future Product Identification Code
Handling by robots of physical objects of unspecified shape and size is traditionally done by the robot trying to perform image processing and recognition of the object before picking it up. This involves significant computational resources. Dr. David Brock of MIT asked how easy it would be if the object could tell the robot about itself and indicate the best way it could be grasped. Independently, Prof. Sanjay Sarma of MIT was concerned about the problem of fixturing and asked if it was possible to place a fiducial on the workpiece to make it easier to locate in space. These questions prompted a search for a solution with RF tagging technology. The traditional approach assumed that physical objects are 'dumb' and tried to make the robot 'very smart'. The tagging approach tries to make these 'dumb' objects tell 'slightly smarter' machines about them- selves.
2.1.1 The Current Bar Code
A bar code is a machine readable code consisting of a series of bars and spaces printed in pre- defined ratios. A bar code reader is used to scan the bar code and convert the visual image into an electrical signal. The information encoded in this electrical signal is then processed by a decoder. The data in a bar code is a reference number which the computer uses to look up associated com- puter disk record, which contains pertinent information, such as price. The bar code also contains descriptive data, such as model number and size. However, the UPC bar code uniquely identifies an SKU, but not the Individual Inventory Items in the SKU group. There are a number of different bar codes. Table 2.1, which sorts the new bar codes from the old, is elaborated in Bar Code Primer published by Worthdata [12].
The UPC bar code is normally a 12-digit, all-numeric code which identifies the consumer package [6]. The code consists of a one-digit Number System Character, a five-digit Manufacturer Identification Number, a five-digit Item Code, and a one-digit Check Character. The UPC-E Sym- bol uses eight digits of numeric data from the UPC by eliminating or suppressing zeros. However, UCC 1 specifies that UPC-E should always be stored as a 12-digit number.
1. Uniform Code Council
17 Bar code Variable Allowable Characters Length Industries in use
OLD
Code I yes 0-9 AT&T pre 1990
Codabar yes 0-9 $ +. : Blood Banks, Cotton, Transportation
Plessey yes 0-9 A-F Shelf Labels
MSI yes 0-9 Shelf Labels
2 of 5 yes 0-9 UPC Shipping Container
UPC/EAN no 0-9 Food/Discount Store Items
NEW
Code 39 yes 0-9 A-Z / + - % $Spc (2 character LOGMARS, HIBCC, pairings for Full ASCII) AIAG, TCIF
Code 128 yes Full ASCII UCC-128, EAN-128
Code 93 yes 0-9 A-Z / + - % $Spc (2 character HIBCC Alternative, pairings for Full ASCII) Canadian Postal Service
Table 2.1: Old bar-codes and New bar-codes
2.1.2 The ePC in Comparison with the UPC bar code
The ePC is a numbering scheme which can uniquely identify physical objects. Information about the object is not stored directly within the code. Just as the UPC bar code serves as a refer- ence to information on a computer, the ePC serves as a reference to information, which pertains to a physical object, on the Internet. In this way, the UPC bar code and the ePC are similar in concept. However, there are significant differences in the implementation, which prove that the ePC embed- ded in RF Tags will serve adequately as the future product code. The most significant difference is that the ePC identifies every Individual Inventory Item in the SKU group, unlike the UPC bar code. These differences, which are detailed in Table 2.2, are elaborated by the Auto-ID Center [1] and Motorola [II].
18 UPC bar code ePC embedded in RF Tags
The UPC allows unique identification for up The proposed numbering scheme of the ePC, to I million manufacturers, each producing which is described later in this section, will 100,000 Stock Keeping Units or SKUs. The allow unique identification for - 16 million code does not carry enough data to uniquely manufacturers, each producing -16 million distinguish individual packages within an SKUs, each in quantities of I trillion Individ- SKU group. ual Inventory Items [7].
Available UPC bar code numbers are Since the ePC can identify an extremely large expected to be depleted within a few years. number of individual products, it will not run out. In any case, if it does run out, it can be easily expanded in future versions to a greater number of bits.
While the UPC bar code has mechanized data Monopole-coupled Bistatix Tags by Motorola capture, it has not been possible to reliably do not require orientation. However, some automate the process. Bar codes require line- inductive RF systems require limited orienta- of-sight reading at a specific angle or range of tion options, requiring parallel planes of both angles. Such orientation problems require Reader and Tag, which can be little or no human intervention. improvement over bar code systems.
Bar codes are printed on the package of the RF Tags will read through nonmetallic coat- product. So, there are affected by dust ings of dirt, dust, and paint without a buildup, ink bleeding, stray marks, dropouts, decrease in performance. It is difficult to label damage, and label tampering. tamper with these Tags, especially when they are embedded.
Since bar codes are printed, they can be easily It is not possible to copy RF data via mechan- copied. ical means. Encryption techniques can make it virtually impossible to replicate a Tag by unauthorized means.
Bar coded information cannot be edited. Read/write RF Tags provide the benefit of the ability to change data.
Table 2.2: UPC bar code vs. ePC embedded in RF Tags: Implementation Issues
The ePC requires the following parameters to determine its design [1]: - The number of bits needed to provide a unique identity to every single product anywhere in the global supply chain. - The decision to partition the available sequence of bits, or not. The strategy for partition- ing the available number of bits, considering the two conflicting objectives of maximiz- ing the number of unique permutations of ePCs and also expediting Internet searches.
Table 2.3 shows a comparative evaluation of different numbering schemes of the ePC [13].
19 Type Advantage Disadvantage
Sequential numbering by 1. All bits in ePC are fully uti- 1. Book-keeping of ePCs Fab, irrespective of manu- lized. in supply chain becomes facturer 2. Cheap. difficult. 3. The ePCs can be regulated. 2. ONS is non-hierarchical. 3. Local cache of SKU- specific information is not possible.
Manufacturer code is pre- 1. Book-keeping of ePCs in 1. Less utilization of bits in determined and the other supply chain is easier. ePC. two codes are requested 2. ONS is hierarchical. 2. Since a manufacturer from Fab periodically 3. Local cache of SKU-spe- depends on the Fab for cific information is possible. Tags, there might be short- 4. The ePCs can be regulated. ages or delays. 3. Changes in product mix cannot be flexibly sup- ported by ePC numbering. Fab provides EPROM with 1. The 'write once, read 1. Cost/Tag increases only the manufacturer code many' functionality is avail- because of more expen- set. Manufacturer sets the able to the manufacturer. sive capital equipment and other two codes. 2. Changes in product mix can programming time at man- be flexibly supported by ePC ufacturer. numbering. 3. The ePCs can be regulated.
Manufacturer's choice rules 1. Completely custom solu- 1. Cost/Tag increases tion. because of more expen- sive capital equipment and programming time at man- ufacturer. 2. Regulation of ePCs is more difficult.
Table 2.3: Numbering scheme of ePCs
The MIT Auto ID Center has tentatively proposed a 96-bit scheme, comprising the following: - Header 8 bits - Manufacturer Code of 24 bits corresponding to over 16 million unique IDs - Product (SKU) Code of 24 bits corresponding to over 16 million unique IDs - Serial Code of 40 bits corresponding to over I trillion unique IDs
The partition, which corresponds to the Manufacturer Code, is required to identify the PML Server, on which information about the object can be found'. The partition, which corresponds to
1. Refer to ONS in Chapter 3 also.
20 the Product Code, is required to identify the general unit-independent characteristics of the prod- uct. When another unit of the same product enters this network, then the system already has infor- mation on this object in the cache. This will facilitate retrieval of general product information from local caches, thereby reducing the number of requests to the PML Server. Since the ePC contains a fixed number of bits, fixing the partitions of Manufacturer Code and Product Code leaves out a bit sequence of fixed length. Hence, the Serial Code is of fixed length.
The Serial Code allows every tagged item to be uniquely identified. This 40-bit Serial Code allows for over 1 trillion uniquely identified objects for each of the over 16 million SKUs. As a result, each manufacturer is allowed more than 18 quintillion uniquely identified items. Therefore, the numbering scheme of the ePC should be more than sufficient from now to the indefinite future.
2.2 The ePC as Device ID: Local Area Networking of Physical Objects
A variety of solutions are available for networking physical objects in a local area network. JiniTM, X1O, RS232, and Microsoft's Universal Plug and Play are a few of the wired solutions. Bluetooth, Wireless RS232, and HorneRF are a few of the wireless solutions. During this project, we implemented a software module with JiniTM and initiated the process of obtaining a Bluetooth development kit. Hence these two are discussed below.
2.2.1 Resource Discovery: JiniTM
JiniTM connection technology is based on a simple concept: Devices should work together without the need to find drivers and without facing problems of incompatibility among operating system [8]. JiniTM makes computers and Devices able to quickly form spontaneous networks. In this federation of Devices, including computers, printers, and sensors, Devices need to be simply plugged in to the network to be functional. Each Device provides an interface to services which may be used by other Devices in the com- munity. Devices and their corresponding services are registered with a local lookup service. When a new Device is plugged in, it first embarks on a discovery of the local lookup service and joins the federation. JiniTM technology also defines a mechanism, which is called the leasing and transac- tion mechanism, to provide resilience for temporary associations in a networked environment.
The ePC and JiniTM can complement each other, as described below. Assume that every Device has an ePC. The services offered by this Device are described in a remote file on the man- ufacturer's PML Server. As we will see in the next chapter, this file is the PML file. When a Device enters the network, it begins its process of discovery of the network and registration with the lookup service. The Device needs to tell the lookup service only its ePC. The lookup service contacts the Device manufacturer's PML Server for the Device file via the ONS, which is described in the next chapter. The lookup service downloads the description of services that this particular Device offers. Therefore, the Device need not have a JiniTM chip that runs JiniTM (and Java) to actually be a part of a federation of JiniTM Devices. As long as the Device can tell the lookup service its ePC, it can be a part of a JiniTM federation. This reduces the cost of Jini TM-com- patible Devices. Our implementation of JiniTM technology in the 'Inventory Tracking Software Module' is described in Section 3.4 of the next chapter.
21 2.2.2 Bluetooth
Bluetooth [9] wireless technology operates in a globally available 2.4 GHz band. The Blue- tooth specification answers the need for short-range wireless connectivity within three application areas, namely real-time voice and data transmissions, elimination of the need for numerous and often proprietary cable attachments, and ad-hoc networking. The specification supports both point- to-point and point-to-multipoint connections - up to 7 active slave Devices can communicate with an active master Device. Though, the number of Devices is actually unlimited, only eight Devices can be active at any given moment. It provides data security by encryption, authentication, fre- quency hopping, and automatic power adaptation to reduce required range. It provides protection from interference in noisy environments by advanced error-correcting methods. It supports data transmission rates of IMbits/sec and a range of approximately 10 meters, which can be extended to over 100 meters with the use of amplifiers.
Consider the following scenario which will be enabled by the synergy of ePC, ONS, JiniTM, and Bluetooth. A cell phone is a physical object and hence, will have an ePC. Consider that the cell phone also implements a resource discovery protocol over Bluetooth wireless interface. As soon as the cell phone enters a JiniTM-compatible LAN I with a Bluetooth interface, it starts the process of discovery and join. Now the cell phone has access to the services offered in the JiniTM federation. Each Device in the federation will have a user interface, which can be stored in the remote PML Server of the manufacturer. The cell phone downloads the user interface from the manufacturer by sending the ONS the Device's ePC. Then, the user can command the Device by sending it instruc- tions locally over Bluetooth.
2.3 The RSVP Proposal
2.3.1 The Problem
The problem that will be considered here is how a particular entity may be tracked efficiently when it is continually in different associations during the course of its existence [14]. If a particu- lar bit in the ePC of the physical object is set, it will instruct the Readers that such a physical object definitely needs to be tracked; however, the Readers can choose to track all objects that they detect.
2.3.2 A Solution in the Style of TCP
Here we will use the fact that an entity moves from one association to another during the course of its life. At the interface of two associations, the control of the entity is handed from one to the other. So, an observer of this transaction will be able to say in which association the entity is, by querying whether the transaction occurred. An association is an aggregation of various entities with certain relationships among them. This set of interrelationships introduces constraints on the possible locations of an entity. These constraints reduce the efforts involved in responding to a query to determine where the entity is located. Sensors, such as RF Readers, detect RF Tags on physical objects and can locate them. Our solution is in the style of the Transmission Control Pro- tocol (TCP) of the TCP/IP2 protocol [15], [16].
1. Local Area Network 2. Transmission Control Protocol / Internet Protocol
22 Main Controller
5 Lost Found S2 3 4 List List 6
Figure 2.1: RSVP Proposal I I ii
Consider the system in Figure 2.1. Each box with a number in it represents an RF Reader, which is a type of sensor. The arrows schematically represent the communication between two sensors. The three Lists will be described later in the discussion.
2.3.3 Assumptions
1. All possible movements of the object from its present location to the next location are known a priori. This assumption makes use of the fact that entities in an association are governed by certain relationships, which impose constraints on the movement of an object. If the movements are not known a priori, they can be determined by dead-reckoning. Algorithms for dead-reckoning are described in [17].
2. A sensor behaves as a Sender when an object leaves it. It behaves as a Receiver when an object arrives at it. These two functions are present in any sensor; however, the sensors need not be intelligent enough to perform this function. All that a sensor has to do is notify the Main Controller about arrivals and departures of objects. The Main Controller can then perform Sender/Receiver function for each sensor and also, maintain the Lost List and the Found List. Thus, the functions and the Lists are only for clarity of concept.
3. One sensor detects at most one object. This assumption can be dropped when RF Readers can resolve collision, the event when multiple RF Tags respond to a Reader simultaneously.
4. One object may be detected by at most one sensor. This assumption may be honored by a suitable firing sequence of sensors, sensorfusion techniques, or other techniques.
5. All the sensors in the system need not be activated continually. They can be activated during discrete intervals of time. Given a discrete time interval, all the sensors need not be activated -- there can be an optimal sensor activation sequence determined for a system-specific objective. The system samplingfrequency is the inverse of the sum of the activation sequence time interval and the quiescent time interval. The system sampling frequency should be at least the Nyquist fre- quency [18] of the system, which is twice the maximum frequency of occurrence of an event, such as the motion of objects in the system.
23 2.3.4 Sender Function
The Sender sends the message [objectePC, time_sent, SenderePC, {PossibleReceiverePCs}], which means "respond when one of you PossibleReceiverePCs receives this objectePC that I have sent at timesent", to a set of sensors that are likely to receive the object [assumption 4.]. To determine this set of PossibleReceivers refer assumption 1. In Figure 2. 1, sensor s sends 4 such a message to sensors sj and s6 -
Within a specific Waiting Time S, if the Sender receives a message [object_ePC, time_receipt, ReceiverePCj which means "ReceiverePC received this object_cPC at timereceipt" True: then physical objects are moving as expected. False: then it posts a [object_ePC, timesent, Sender ePCI on a Lost List [refer to Section 2.3.7] and lets the Main Controller take action.
2.3.5 Receiver Function
Consider the event when a sensor receives an object.
Receiver checks on its Receiver List if there is any Sender sensor that it has to respond to: True: then the Receiver replies to the Sender with the message [object_ePC, timereceipt, ReceiverePC] that it has received the object. False: If so, it checks if this object is placed on the Lost List [refer to Section 2.3.7]: True: This will happen if the object was not received during the Waiting-TimeS of the Sender. The Sender would have placed this object on the Lost List. Receiver deletes the object from Lost List and lets the Main Controller analyze why movement of the object from Sender to Receiver was delayed. False: This occurs when an object is found at a Receiver that was not expected to get the object. It adds the object to Found List [refer to Section 2.3.7] and lets the Main Controller take action. The Main Controller has the capability to delete an item from the Found List.
Suppose a PossibleReceiver sensor, say sensor s5 , receives "respond when you receive this objectePC that I have sent at this time" but does not receive the object, then it will time out after WaitingTime_R, which may or may not be equal to WaitingTimeS. The PossibleReceiver deletes the entry [object_ePC, time_sent, SenderePC] from its Receiver List. Whenever a sensor receives this object, it performs the checks as described above. If this object is on the Lost List for longer than a WaitingTimeMainC, the Main Controller can take action. The occurrence of a lost object will be handled by the Sender, sensor s4 . The reason is that the object was definitely at the Sender. It is only after this stage that the object was lost. Hence, only the Sender should decide if an object is lost or not. In other words, only the Sender can write on the Lost List.
24 2.3.6 Boundary Conditions
At the input of the system, the sensors which receive objects will need to respond to no Sender sensors regarding the receipt. By stepping through the Receiver algorithm, the sensor places them on the Found List and lets the Main Controller take action. The Main Controller deletes them, as necessary, from the Found List. So, the Main Controller has a guarantee that the objects have actu- ally entered its system. At the output of the system, the Sender sends the message to its PossibleReceivers. If all these messages are routed through the Main Controller, then such messages can be handled appro- priately. This can also serve as a check that no objects have been lost inside the system. The Main Controller can then transfer control to its succeeding Controller. The functions of the succeeding Controller are similar to that of the previous one.
2.3.7 Data-structures and Algorithms
The Lost List, the Found List, and the Receiver List need to be implemented with efficient dynamic data structures that support dictionary operations, such as searching, insertion, and dele- tion. Randomized binary search trees, red-black trees, and heaps support the dictionary operations in O(log(n)) time, where n is the number of elements in the data structure. This result has been reported by Cormen, et al [19].
2.3.8 Solution of the Original Problem
The original problem is described in Section 2.3.1. Now we are given that we have an RSVP protocol implemented in each of the associations that a physical object, which has an ePC, goes through during its lifetime. The Main Controller in each association has information on when an object enters and leaves the system under its control. Therefore, it is possible to determine the location of an object at a particular time by querying an association that it has definitely passed through. A brute force method to find a particular object would require querying the Readers in all installations in the world. Such an approach would be highly inefficient. The RSVP algorithm que- ries only a subset of all the Readers, which is most likely to have detected the object at some point in time. Therefore, it is more efficient than the brute force method.
The RSVP algorithm can be used to prevent theft in a retail store. Consider a store that con- tains a shelf, a checkout counter, and the doorway. Place a sensor in each of these three locations. When a store item is removed from the shelf, the system excepts to see it at the checkout counter. If the system sees the item at the doorway prior to having observed a checkout, then the system knows that a theft is possibly in progress.
25 26 Chapter 3: Information Storage and Retrieval Layer
PML and ONS, which we introduced in Section 2.2.1, are explained in this chapter. We present background material on XML in Section 3.1.1 and describe it as not only a markup language, which it was originally, but also a data exchange format and a data model. We present background information on the XML famil y, which includes a query language and a style sheet language, in Section 3.2.9. We present our insight into the data model of XML in Section 3.2.3, implementation issues in Section 3.2.6, and collaboration issues in Section 3.2.7. The client-server application, which uses XML, XQL, and JiniTM, to track physical objects moving in a remote location, is described in Section 3.4.
3.1 eXtensible Markup Language
Physical objects often have associations with other physical objects; for example, a box on a pallet in a factory, a microwave oven and a refrigerator in a kitchen, or a valve in the engine of a car. A microwave oven and a refrigerator in a kitchen represents an association, in which two objects are contained in another. The two objects are themselves related by the fact that they are both present in the kitchen. Structures, such as the above, repeat recursively to create a deep and broad tree or hierarchy of physical objects. The tree is an association of entities that have relation- ships among them, as shown in Figure 3.1. Therefore, physical objects can be organized into a hierarchy depending on their associations with each other. When we think of a hierarchy, it is useful to consider the parent-sibling relationship, which is an important relationship in object-oriented programming [22]. As an example, we consider relationships of containership (has a) and inheritance (is a). To illustrate these relationships, consider Procter & Gamble which manufactures different detergents [23]. Almost all detergents have a certain set of characteristics or attributes, such as active ingredients, mass, relevant patents, storage/disposal, poison control, directions of use, presence/absence of bleach, and similar products. 'Detergent' may be considered an abstract class, which contains 'Active Ingredient' class among others. 'TideR' class inherits from 'Detergent' class and may be considered an instantiation of 'Detergent'. Physical objects can have other relationships among themselves besides the ones mentioned above; for example, part of, which is the inverse of has a, and version of.
------20
3 ]:Association 02:Entity / \3:Relationship
Figure 3.1: Tree structure of the environment of physical objects
27 knowledge information increasing level of data - intelligence
Figure 3.2: Data, information, and knowledge
Consider the difference between data, information, and knowledge, as illustrated in Figure 3.2. Data may be considered as the fundamental unit of information and knowledge. In the physical world, a good example of data is the temperature read by a sensor in a car engine. Information is the fact that this temperature is higher than the maximum allowable temperature, which is determined by the car's on-board computer. Knowledge is the 'understanding' of the car's computer that the temperature rise indicates that a servicing is due, by the consideration of other sensor data, such as the quantity of lubricant, fuel efficiency, and tire pressure. A physical object, which handles only data, is less intelligent than an object, which provides information by interpreting the data. The latter system is, in turn, less intelligent than a physical object, which puts this information in context with other information to derive insight or knowledge. A more intelligent physical object, such as a computer, interprets the operation of less intelligent physical objects, such as a temperature sensor. Therefore, physical objects can be arranged in a hierarchy based on their level of intelligence.
Thus, physical objects can be organized into hierarchies based on their interrelationships and their level of intelligence.
3.1.1 XML in Brief
The key features of XML as elaborated by Bos [24] are as follows:
1. XML is a set of rules or guidelines for designing texti formats for data. It is a meta-language which lets a person or organization design their own markup language depending on their needs. XML is an open standard supported by W3C [5].
2. XML data is organized into an abstract tree structure. Therefore, it is the ideal language to maintain information about physical entities that are part of the association hierarchy. There is no ambiguity regarding the scope or the relationship of piece of data to other data. Since XML is an abstract data model, it can also be used to model other relationships. Section 3.2 elaborates the concept of XML as a data model.
3. Like HTML, XML makes use of tags and attributes, but while HTML specifies how the text between the tags should appear in a browser, XML uses the tags only as meta-data 2 and leaves the interpretation of the data completely to the application that reads it. Thus, a tag can be considered as the most fundamental unit of information.
1. think of text as a form of a data storage format using binary digits, and not as a display format. 2. data about data
28 4. XML data is stored or exchanged in text format. Text is platform-independent and therefore, XML is also. Text format allows programmers to more easily debug applications using text edi- tors, while also making it easy for a computers to read and generate data. The WAPForum [4] is in the process of defining a WAP Binary XML Content format for encoding the XML which is used in wireless applications, in which there are constraints of lower bandwidths and unreliable connec- tions. Binary XML preserves the logical element structure, encodes the parsed physical form of an XML document, and removes meta-information, such as comments and Document Type Defini- tion or DTD [5].
5. Since XML is in text format, XML files are almost always larger than comparable binary formats. This disadvantage is not very serious for the following reasons: disk space is relatively inexpensive; programs, such as zip and gzip, can compress files very well and very fast; and com- munication protocols, such as modem protocols and HTTP/1.1, can compress data on the fly, thus saving bandwidth as effectively as a binary format. The problem with data-exchange in text format is that it needs to be parsed before any dictionary operations can be performed on it. Section 3.2 describes XML as a data format.
6. XML is a family of technologies. Around XML, there is a growing and extensible set of optional modules that provide sets of tags and attributes, or guidelines for specific tasks. A brief description of the XML family is provided in Section 3.2.9.
7. XML originated from research in document markup, and now is expected to become the universal format for data exchange on the Internet. Before XML there was SGML, developed in the early 1980s, an ISO standard since 1986, and widely used for large documentation projects. HTML was developed in 1990. The designers of XML simply took the best parts of SGML, used their experience with HTML, and produced XML which is no less powerful than SGML, but vastly more regular and simpler to use.
3.2 XML data format
3.2.1 Data, Meta-Data, Relationships, and Documents
In XML, data is the fundamental unit of information. Referring to Figure 3.2, meta-data is the fundamental unit of knowledge because it specifies the context of the data. For example, 'Washington' is data, but it is not possible to say whether it is a person, place, or thing. However, when it is specified as
29 In Table 3.1, we distinguish between data-centric and document-centric documents [25]. Though Table 3.1 applies substantially to any general document, some of the statements are specific to XML documents.
Data-centric Documents Document-centric Documents
The data has regular structure and is fine- The data is large-grained with less structure grained. The smallest independent unit of than that in data-centric document. The data is an element, which contains only smallest independent unit of data might be Parsed Character Data (PCDATA), or an an element with mixed content, which is attribute. both PCDATA-only elements and other ele- ments, or the entire document itself.
Document has little or no mixed content. Document has lots of mixed content.
The sequential order of attribute values and The order of attribute values and sibling sibling elements is insignificant. elements is very significant.
Such documents are primarily for machine Such documents are primarily for human consumption. consumption.
A database system, such as a Relational A Content Management System (CMS), Database System (RDBS), is used to store which lies over a database system, is used. such documents. When storing such a docu- RDBS do not satisfy requirements of a ment in the database, it is often acceptable to CMS, such as order, hierarchy, fields of discard information about a document, such variable length, and irregular structure. as its name, DTD, and physical structure Hence, hierarchical or object-oriented data- (such as the sequential order in which bases are used for CMS. It also has extra attribute values and sibling elements occur), features, such as thesauri and search Character Data (CDATA) sections, entity def- engines. inition and usage, the way in which binary data is stored, and encoding information.
Table 3.1: Data-centric and Document-centric Documents
It has been said that XML facilitates convergence of relatively unstructured documents and structured data into a structured document format. This is because: - Data needs to be delivered as an integrated part of scientific or business documents " Document Content has meta-data that needs to be queried, analyzed, and manipulated without necessarily accessing the actual chunks of media content. This is currently rele- vant to search engines that index the web. Section 3.2.10 mentions meta-data searches with Google search engine. Figure 3.3 provides a simple illustration of how XML integrates data into document-centric documents.
30
Figure 3.3: Integrating data into document-centric documents
3.2.2 Data Models
To hide the complexities in database systems from various levels of users, database systems are considered at three levels of data abstraction [26], as shown in Figure 3.4. This is done with the aim of providing data independence between any two levels. - Application or View level - Logical level - Physical data level
The overall logical design of the database is known as the database schema. A database schema corresponds to type-definition in programming languages. Each data abstraction level is associated with a schema. The database system comprises the Logical level and the Physical data level.
view 1 _Application or View Level - _ - view n
------'------Historical migration ol Logical Level complexity Database System Physical Data Level
Figure 3.4: Levels of data abstraction and Migration of complexity
31 Database technology has undergone four generations of evolution, and the fifth one is underway [271. Refer to Appendix B for a very brief description of the generations of database systems. The transition from one generation to the next has been characterized by moving the complexity (or tedium) of database functions from the applications level to the database system, which comprises the logical and physical data levels. This was facilitated by providing richer data models in the logical level and more functionality in the physical data level; for example, the introduction of declarative queries in RDBS, relieved application programmers of programming the navigational retrieval of records from the database, but required the addition of the query optimizer to the database system to ensure efficient database functions.
A data model [26] is a collection of conceptual tools for capturing in a model, real world entities and their interrelationships, which are associated with a problem that requires a database solution. Data models differ in the primitives available for describing data and in the amount of semantic detail that can be expressed. A data model is primarily a logical level model. The various logical data models that have been proposed fall into different groups: 1. semantic data model Such as the Entity-Relationship or E-R data model, DAPLEX functional model, and Semantic Data Model. These models express the most rich set of semantic relationships among real-world entities as described by Kim [27]. The other data models can be considered as subsets of a semantic data model. 2. record-based logical models Such as the Relational model, Network model, and Hierarchical model. The corresponding databases are structured in records having fixed number of fields/attributes, each of which is usually of fixed length. 3. object-oriented data model This models captures 'generalization/specialization' relationship between super-class and class, 'instance-of' relationship between an object and its class or super-class, and 'aggregation' or 'contains' relationship between a class and its attributes. Kim [27] mentions additional semantic relationships, such as 'version-of' and 'part-of', which can be considered as the inverse of 'contains' relationship. A class can maintain a static attribute that aggregates information from all its instances a very simple example, is a static variable that maintains a count of instances of the class. 4. object-relational data model This model extends the relational data model by providing a richer type system including object-orientation.
In contrast to logical data models, there are few physical data models [26]. Two of the widely known ones are: 1. Unifying model 2. Frame-memory model
One of the requirements of a data model is that the model should allow an applicationslevel database designer to convert with ease and with complete richness of relationships, her conceptual model of the real problem into a logical level database schema. A conceptual model can be designed with a semantic data model because it offers the richest relationships. If the real problem
32 customerla
nRame ) address loanID) amount
Figure 3.5: E-R semantic data model to construct a bank schema displays a relationship, which cannot be directly modeled with the relationships specified in the logical data model, then an ad-hoc relationship needs to be created and its functionality has to be implemented in the application level. This is opposite to the direction of the historicalmigration of complexity, which is illustrated in Figure 3.4, and has motivated the development of the next generation of database languages. For example, with the popularity of relational databases for business applications in the early 1980s, attempts were made to use relational databases in CAD, CAE, CASE, and CAM. These areas need to model complex and nested relationships, which are very difficult to implement using relational tables. Hence, applicationslevel programs were forced to handle this impedance-mismatch' between the real world and the data model. This motivated the development of object-oriented data models.
When we consider a generic XML document, it is not immediately obvious what the data model is. This is because XML has its own implied data model, which is neither that of traditional relational databases nor that of object oriented or object-relational databases. XML is an abstract data model. Though XML is an abstract data model, a specific instance of an XML data model for a real problem may map conveniently to a currently implemented data model, such as the relational or object-oriented data model. This is an issue which we illustrate in the Section 3.2.3.
3.2.3 Creating XML documents from Entity-Relationship data model
The question that will be considered here is: Given a semantic data model for a particular problem, how should the XML documents' structures be designed? These documents will be used in inter-operable data-exchange among different database systems. So, they will be exchanged in textformat, and will have to be parsed into an efficient data-structure in memory.
Consider how the E-R 2 semantic model would be used to construct a database schema for a bank in Figure 3.5. There is a many-to-many mapping, called cl, between customer and loan
customer lla name oanDloan name address loanID amount
Figure 3.6: Relational data model of bank schema
1. This is jargon prevalent in database community. 2. Entity-Relationship
33 customer namne ell address mtos customer. loan la methods la Ioanl I_ composite amouint attributes methods
Figure 3.7: Object-oriented data model of bank schema entities [26]. This has to be implemented as a data structure that can respond efficiently to queries, such as "Give the addresses of all customers whose loan amount is greater than $20". Since the E-R data model is a semantic data model, it can express the richest set of semantic relationships among real-world entities [27]. The other data models can be generally considered subsets of a semantic data model. We present the relational data model in Figure 3.6, and the object-oriented data model [27] in Figure 3.7. Both the models correspond to the E-R semantic data model in Figure 3.5. In object-oriented data model of Figure 3.7, cl, customer, and loan are classes. Composite reference [27] means that there is a relationship which specifies that an attribute is a part-of a class. This is like the inverse of the relationship which specifies that the class contains an attribute.
In Figure 3.8, we present XML text documents, corresponding to the E-R semantic data model. The dotted lines represent uni-directional pointers that link
customer.xml
Figure 3.8: XML text file to represent the E-R data model
34 wthods 10a anml " richCustomer gradStudent company school methods methods
Figure 3.9: Object-oriented data model of bank schema, with inheritance
customer.xml
richCustomer.xml gradStudent.xml
Figure 3.10: XML text file to represent the inheritance
We introduce more complicated relationships in the data model by including inheritance relationships, as shown in Figure 3.9. There are two types of customers - rich customers and graduate students. We can design XML text documents to capture these relationships, too. The corresponding XML text documents for customer and its children are shown in Figure 3.10.
Our conclusion from this section is as follows. As was pointer earlier, XML documents are exchanged in text format to facilitate inter-operability. When these XML text documents are parsed, the relationships will need to be interpreted by a mapping software, which maps the logical structure of the XML document into the efficient database system. For example, the XML document structure of Figure 3.8 and Figure 3.10 can be efficiently implemented without impedance-mismatch in RDBS and ODBS respectively. So, depending on the type and complexity of relationships in the semantic data model, it might be convenient to map the semantic data model to an RDBS or an ODBS, or any other. Hence, we can say that though XML is an abstract data model, a specific instance of an XML data model for a real problem may map conveniently to a currently implemented data model, such as the relational model or the object-oriented model. If there is impedance-mismatch in such a mapping, it means that the relational or the object-oriented data model is not able to model the
35 complexity of relationships in the semantic data model. For instance, this might happen when relationships among physical objects are modeled. Hence, when it becomes necessary to map such complex relationships to an efficient database implementation, we may need another generation of database systems. Meanwhile, for problems with complex relationships, special mapping software will be required in the database system application to interface with the XML parser and interpret relationships.
3.2.4 Logical Structure of XML
In the previous Section 3.2.3, we discussed how the XML data model can represent complex relationships, which need to be interpreted by a mapping software that interfaces with the XML parser. Now, we present the XML abstract data model as specified by the W3C. The Document Object Model [5] represents documents by a logical structure, which is like a tree or a forest of nodes. The DOM provides a standard set of objects for representing HTML and XML documents, a standard model of how these objects can be combined, and a standard interface for accessing and manipulating them. Consider the XML file shown in Figure 3.11 and its DOM representation shown in Figure 3.12.
Detergent
Ingredient Diretis
Chemical Chemical x with w
abc rxyz
Figure 3.12: DOM representation of the XML file in Figure 3.11
36 It is important to note that the DOM is an abstract model which specifies the interfaces that must be supported to manage XML or HTML documents. It does not specify that the data structure implementation of a document should be a tree or a grove of nodes or any other, does not specify the data-structure of the node, and does not specify how the relationships among objects should be implemented. Vendors can support the DOM as an interface to their proprietary data structures, and content authors can comply with the standard DOM interfaces rather than product- specific interfaces, thus increasing inter-operability on the Web. The DOM does not define what information in a document is relevant or how information in a document is structured. The W3C XML Information Set [5] specifies the information in an XML document. The DOM is simply an Application Programmer's Interface (API) to this information set.
The DOM of an XML or HTML document provides the following abstract relationships: 1. Hierarchy parent/child ancestor/descendant 2. Sequence (within a sibling list or in document order) immediately precedes precedes 3. Position (within a sibling list or in document order) absolute relative ranges
3.2.5 XML Text Parsers
Besides DOM, SAX is the other popular API for manipulating XML documents [28]. SAX was originally designed specifically as an API for XML parsers. Table 3.2 presents the comparison between these two parsers which convert XML text documents into a representation in the computer's memory. It is possible to combine SAX and DOM within a single system. Many parsers can produce both SAX and DOM output. Despite the impedance mismatch between them, it is not uncommon to use a SAX stream as input to a DOM builder, or to use a DOM's contents to generate SAX events.
3.2.6 Implementation Structure in XML
The first step in implementing a database system for a problem is to design the logical structure of the data model from an analysis of the problem One of the ways is the use of the Entity-Relationship technique described in [26]. A data model has a logical structure, and the database system corresponding to the data model has an implementation data-structure, but these two need not be the same. The foremost issue in implementing the data model is to choose the implementation data-structure. The properties of the data-structure will determine the performance of the database system in each dictionary operation, such as inserting, deleting, and querying.
37 XML-text-to-DOM Parser SAX Parser
Parses an XML text document into an DOM Parses an XML text document into a serial- representation, which has a logical tree data ized event stream, where the recognition of model, in the computer's memory. of a chunk of XML syntax is an event, which should be handled by a handler function. It is oblivious of any logical data model within the document. SAX does not support ran- dom-access manipulation of data within the document.
Used when an inter-operable, W3C-standard- 1) Used when it is necessary to implement a ized, complete, and editable view of docu- custom (not tree) document model. ment needs to be provided to foreign 2) Used when applications need to view the applications. document in a linear flow, for example, when looking for a particular XML tag. 3) Used when the XML document is not intended for inter-operability and ability to edit.
This parser is standardized by W3C. SAX was originally designed specifically to be an API for XML parsers by the XML-dev developers mailing list.
I) They often put a great strain on system During parsing, it is possible to discard resources, especially if the document is large. information that will not be needed. This can 2) When applications need to build their cus- result in smaller requirement of memory tom data-structures, it is very inefficient to than that required in retaining a complete build a tree of parse nodes, and then map it DOM model. into the required data-structure. 3) All W3C-specified interfaces need to be supported for the document model to be valid as a DOM.
Table 3.2: XML-text-to-DOM Parser vs. SAX Parser
For instance, consider an XML document. The corresponding DOM has the logical structure of a tree or a group of trees - a forest. If it is also implemented as a corresponding tree data- structure, then, in the worst case, a dictionary operation will have to work its way down through the depth of the tree. This worst case running time is O(depth of tree). Where n is the number of nodes/tags, the depth of the tree can range from log(n) to n, depending on the logical structure of the XML document. This running time is not very efficient and there are other data-structures which support a subset of the dictionary operations in amortized O(1) time [19]. For instance, Fibonacci heaps support insert and query-for-minimum-element in amortized O(1) time.
38 3.2.7 Practical Issue of Collaboration
An XML data file in text format has to be parsed and mapped into the chosen data-structure in the computer's memory. While parsing tags in text format, the actual word in the tag has significance. For example, consider a parser that can map
3.2.8 Final Remarks on XML
In conclusion, an XML database system is not to be thought of as one that stores data in XML text files, though it can cache XML text files. It should be thought of as a database that can map the XML logical structure into an efficient data-structure. Once this is done, the database system can perform inverse mapping of its data-structure and can generate XML documents. Thus, XML format can be considered as a format to interface with an efficient database system. For example, an RDBS application, such as Oracle, may treat XML and its query language as another interface to its RDBS. So, XML lies in the middle tier between the database and the client. Once XML becomes pervasive, many information sources will structure their external view as a repository of XML data, no matter what their internal storage mechanisms. The Internet can then be viewed at a high level as one very big distributed XML database. This is what is meant when it is said that XML will facilitate web and database integration.
The final point is that XML is primarily: - a data-exchange format among distributed heterogeneous databases for whose success human collaboration is necessary, and - a facility to include meta-data in documents. The rest of the XML family extends this fundamental idea into a useful solution to world-wide information sharing. This is described in the Section 3.2.9.
Applications of XML can be broadly classified as follows: - data and document exchange among two or more heterogeneous databases. " inclusion of meta-information in documents to allow customized information retrieval. This requires that content generators use many specialized tags to convey specific attributes of content, such as subject category, audience category, length, date of creation, reviews, language, etc. " presentationof different views of the same data to different users. - distribution of processing load from the server to the client.
39 3.2.9 Other Members of XML Family
Extensive literature on each of the following members of the XML family can be obtained from W3C [5].
XML Stylesheet Language (XSL) consists of the following parts: XSL Transformation (XSLT), which is a method for transforming XML documents into other XML documents. XSLT is a method to sort the elements, filter elements, and perform conditional tests and make decisions about which elements to display. Though XSLT is also designed to be used independently of XSL, it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL. XSLT imple- ments transformation by example i.e. a pattern matching template, not by program logic. - XSL Formatting, a method for formatting XML documents into a format that a browser can recognize, such as HTML or WML. Normally XSL does this by transforming each XML element into an HTML element. It can also add new elements into or remove old ones from the output files.
These are the following ways of displaying an XML file on a browser: - A pointer to an XSL file embedded in XML document " JavaScript that dynamically loads the appropriate XSL. Using JavaScript to do the transformation from XML to any other format provides more versatility in the form of allowing the JavaScript to do browser specific testing and using different style sheets according to browser and/or user needs.
Java is the inter-operable software language and XML is the inter-operable data format. Currently, Java parsers parse XML text files and convert them to DOM. Client-side processing by Java applets operating on XML-DOM will reduce the number of requests to the server in applications when the client is considering various alternatives. For example, an airlines customer trying to choose tickets depending on fare and schedule [29] will see tables that can be sorted by any column by clicking on it. Different views of the same data can be handled by client-side processing instead of by repeated requests to the server. Thus, the server is also able to provide various views with the same data and with fewer requests to handle.
An XML Namespace is a collection of element type and attribute names. Its purpose is to distinguish between duplicate element type and attribute names. Such duplication might occur, for example, in an XSLT stylesheet or in a document that contains element types and attributes from two different DTDs. The Namespace is identified by a URI. Thus, any element type or attribute name in an XML Namespace can be uniquely identified by a two-part name: the URI of its XML Namespace and its local name. This two-part naming system is the only function of XML Namespaces. An XML Namespace URI is simply an identifier. It is not guaranteed to point to schemas or information about the namespace. Hence, there is generally no reason to resolve them. URIs are used simply because they are a well-known system for creating unique identifiers.
XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. XPath operates on the abstract model of an XML document, which is a tree of nodes but does not specify implementation details. XPath uses a compact, non-XML syntax to allow use of XPath within URIs and XML attribute values. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document.
40 XLink package is a package of hyperlinking functionality that comes in two parts: - XLink governs how links can be inserted into an XML document, where the link might point to anything, for example, a gif image. It is needed because there is no predetermined tag that defines a link, such as A and IMG in HTML. - XPointer governs the fragment identifier that allows linking to an XML document from anywhere, for example, the same or a different XML file or an HTML file. It can be part of a URL.
XLink adds the following advanced hypertext linking functionality to the Web and other environments: - Extended links that allow navigation among multiple destinations from a destination to any other. Bi-directional links are the simplest example of extended links. - Links that annotate read-only documents. The facility to create links that will show up when people view a document even though you don't own the document to build a valu- able infrastructure of annotation, commentary, and communal evaluation and discussion on the Web. - Links with certain special behaviors, such as expand-in-place, new window vs. replace- ment and automatic follows. These behaviors can be programmed now with Java. - Link databases, with all the consequent possibilities for filtering, sorting, analyzing, and processing link collections.
XPointer provides better location specifications: - Links that provide fine-grained addressing to the insides of an XML documents, such as elements and character strings. - Since it uses XPath for addressing parts of XML documents, it can be part of a URL.
3.2.10 XQL
We saw earlier that the Internet can be viewed at a high level as one very big distributed XML database. The motivation for XQL is that a global inter-operable data-exchange format, such as XML, needs an inter-operable query language to retrieve relevant documents from any server in the world. Consider a set of relational databases that each use slightly different SQL languages. If all these databases understand XML and XQL, then a client can use one query to search for data in the entire set. However, XQL is not yet a W3C specification yet. W3C is also working on a draft of the XML-Query Language or XML-QL.
The problem domains in which XQL can be used are elaborated in [30] and are listed below: 1. Queries within a single document (e.g. in a browser or editor). When browsers can compre- hend the XML family, servers will be able to serve XML text files to clients as well as XQL embedded in XSL sheets. This will provide greater flexibility in querying and display. XPointer will allow reference to portions of documents. 2. Queries in collections of documents. In the Appendix C, we have included an example in which XML documents from two different sources are queried and displayed. 3. Addressing within or across documents with XLink and XPointers. This is similar to the links and anchor functionality available in HTML today. 4. As XSL tree-to-tree transformation.
41 Since XML is an abstract data model, the query language XQL will be abstract. XQL expresses all the assertions that might commonly be made about nodes found in an XML document and their relationships to other nodes. The way XQL queries are implemented depends on the way the abstract XML data model is implemented. For example, a relational database might implement the XQL query with SQL.
Traditionally, structured queries have been used primarily for relational or object oriented databases, and document-centric documents were queried with relatively unstructured full-text queries. We saw earlier that XML facilitates convergence of data and documents into structured documents. A good illustration is the Google search engine, which has provided facility for searching in various languages, such as English, Italian, Norwegian, French, and Spanish. The language of the document is basically meta-data about the document. Hence, the finer the meta- data provided, the finer a search can be made. This is also an example of how XML brings together data (or meta-data) and documents.
Since XQL utilizes XPath, XQL expressions are easily parsed and can be used in a variety of software environments - as part of a URL, in XML or HTML attributes, and in programming language strings. XQL or XML-QL will be the standard inter-operable query language of choice to query distributed PML databases.
3.3 PML and ONS
In this section, we have included the definitions of PML and ONS, as described by Auto-ID Center [1]. PML is currently being developed. A version of ONS is ready [3]. These definitions are provided primarily for completeness of this chapter.
The Physical Markup Language will serve as a standard language for describing physical objects. It may be thought of as an instantiation of XML. PML will contain increasingly specific data in order to describe physical objects, their configuration, and state. A PML document will be a data-centric document. The characteristics of PML are as follows: - It should translate or contain static data - such as dosage, shipping, expiration, advertis- ing and recycling information. - It should provide instructions for machines that 'process' or alter a product - such as microwaves, laundry appliances, machine tools and industrial equipment. - It may need to communicate dynamic data: information that changes as a product ages or as it is consumed - such as volume, temperature, moisture and pressure. - It may need to include software, or programs, which describe how an object behaves - for instance: a PML file may contain the program which describes how fast the tires on a car will wear before they need to be replaced, or how fast an object may burn in case of a fire. PML tags are relevant to characteristics of physical products, such as goods in a supply network, sensors, equipment, etc. Since the choice of tags is a policy issue which requires the collaboration of all the manufacturers, we have not discussed the specifics of PML in this thesis.
42 An example of a PML file is shown below: '
The Object Naming System tells computer systems where to locate information on the Internet about any physical object that carries an ePC. ONS maps the manufacturer part of the ePC code to the manufacturer's PML Server IP address. ONS is an application layer protocol above the Internet's existing Domain Name System [21]. This service makes it possible to store large amounts of information on the Internet, instead of on the object or tag, and to find pertinent information to a variety of requests.
3.4 Applications: Inventory Tracking Software Module
The demonstration application, which we developed, consisted of two computers, A and B, in the Auto-ID lab utilizing each other's services via the JiniTM protocol1 . The lookup service for the local network is initiated by one computer. Let us suppose that this computer is A. The computer A also registers with the lookup service, its available service, which is to provide tracking of physical objects. After a while, computer B enters the network and initiates the process of discovery of the lookup service. After registering itself and its services with the lookup service, it queries the lookup service for a particular service, which in this case is the tracking service. Computer B then initiates a request for computer A's service and obtains it.
Computer A is assumed to retrieve and store information received from a sensor network. The sensor network is assumed to be an array of readers, each of which contacts computer A when it detects an object. Each reader corresponds to a two-dimensional cell in the array. The database of computer A is assumed to support XQL queries. In this application, the information is stored in XML text format, whose structure is displayed below. This is loaded into memory as a DOM by parsing the text file with IBM's XML parser.
1. Refer to Chapter 2
43 Computer B requests from computer A the trace of movement of an particular object by means of an XQL query, rawDB/time?//cell[(.='l28')], sent over the JiniTM protocol. Computer A implements the XQL query using the XQL engine, developed by Infonyte [10], converts the resultant XML document to text in memory, and sends it to computer B using the JiniTM protocol. Computer B uses an XML parser to convert the text file to an in-memory representation. It then displays the motion of the object over time.
Such a system can be used in a warehouse setting; for instance, a manager can view on an Internet browser, such as Netscape Navigator, the status of inventory or the flow of goods by accessing the URL of the warehouse. Later in Chapter 4, we will also consider the display of information on the manager's cell phone. Thus, these two applications provide a graphical interface to supply chain information.
There are a lot of application domains which would benefit by integrating physical objects with the Internet and providing information on them anytime anywhere. The application domains include supply chains and 'smart' homes.
The Internet has made it possible for online business to be an economical option. An increasing number of companies and consumers are making purchases and conducting other commercial activity on the web. Consumers have more choices due to their increased awareness facilitated by the Internet. They are also able to switch choices and make purchases more conveniently than before. Companies will perform better if they can respond faster to consumer demands at a lower cost. When RF Tags are attached to consumer goods, it is possible to obtain information about them anywhere in the supply chain reliably and without human intervention. In this way, the factory can determine the sales in its retail outlets much faster. It can take corrective action, such as adjusting production schedules, replenishing stocks, and changing product mix. At the retail store, it is possible to enable automatic check-out besides automatic logging of inventory. As pointed out earlier, the RSVP protocol among RF Readers can also be used to determine a theft in progress.
If a meat packaging factory discovers that the previous week's batch was contaminated, it can easily determine where each individual package is by querying its distribution channels using the proposed RSVP protocol. The factory can also append this vital information to the PML files, which correspond to each individual package belonging to the contaminated batch. A customer's 'smart' refrigerator, which queries the ONS and downloads information on every item it contains, will be able to warn the customer.
In 'smart' homes, the home computer will be able to obtain information on tagged objects in the house. A refrigerator will be able to automatically order milk whenever the bottle is running out. A microwave will be able to determine how to cook the food, whose package is tagged.
44 Chapter 4: Wide Area Access Layer
In this chapter, we describe an implementation of a wireless interface to data from remote sen- sors, which are identified by ePC. In Section 3.4 of the previous chapter, we considered how a warehouse manager can view on his Internet browser the stocks and flow of her inventory. Here, we consider the display of this type of sensor information on a personal mobile device, such as a mobile phone or a PalmVII.
We first present background information on technologies, such as WAP, WML, and WML- Script, in Section 4.1. Then we describe our implementation by the synthesis of these technologies with Java serviets and a BASIC Stamp in Section 4.2. We describe our software for conversion of PML to WML, in Section 4.2.1. We also present our insight into the technology developed in rela- tion to work on control modes in Section 4.3.
4.1 Technologies Used
4.1.1 Wireless Application Protocol
WAP is an open, inter-operable specification that empowers mobile users with wireless devices to easily access and interact with information and services instantly [4]. WAP is a commu- nications protocol and an application environment. WAP is designed with the constraints of small narrowband devices in mind, which are: " Small display and limited user input facilities - Narrowband connection with more latency, less connection stability, less availability - Limited memory, processing power, and power supply
WAP provides end-to-end security between WAP protocol end points. WAP includes a specifi- cation called Wireless Transport Layer Security, which implements options for authentication and encryption. It is optimized for use in the mobile environment. The complete WAP architecture is shown in Figure 4.1.
The types of devices that will use WAP are hand-held digital wireless devices, such as mobile phones, pagers, and two-way radios. WAP is designed to work with most wireless networks such as CDPD, CDMA, GSM, PDC, PHS, TDMA, FLEX, ReFLEX, iDEN, TETRA, DECT, DataTAC, and Mobitex. It can be built on any operating system including PalmOS, EPOC, Windows CE, FLEXOS, OS/9, and JavaOS.
The WAP Forum is the industry association which has developed the de facto world standard for wireless information and telephony services on digital mobile phones and other wireless termi- nals. WAP Forum currently comprises over 200 members, who represent over 90% of the global handset market, carriers with more than 100 million subscribers, leading infrastructure providers, software developers, and other organizations providing solutions to the wireless industry.
45 OtherApplications Servces and
Security Layer (WTLS)
Transport Layer (WDP)
Figure 4.1: WAP Architecture
4.1.2 Wireless Markup Language
WML is a markup language based on XML. It is intended for use in specifying content and user interface for narrowband devices, such as cellular phones and pagers [4].
WML includes four major functional areas: - Text presentation and layout -- WML includes text and image support, including a vari- ety of formatting and layout commands; "Deck/card organizational metaphor -- all information in WML is organized into a collec- tion of cards and decks; "Inter-card navigation and linking -- WML includes support for explicitly managing the navigation between cards and decks; - String parameterization and state management -- all WML decks can be parameterized, using a state model.
46 An example of WML code is presented below: Random.wml Random Number:
$(one)
4.1.3 WMLScript Language
WMLScript [4] is the WAP corollary to the JavaScript scripting language, which was popular- ized by Netscape Communications. Standardization efforts by Netscape helped produce the ECMAScript standard, on which the WMLScript was based. While JavaScript has since been coopted by server tool vendors, such as Netscape and Microsoft, WMLScript is a client-only scripting platform, which is used in combination with WML to provide client-side procedural logic. Like WML, WMLScript is compiled by a WAP gateway into binary form.
WMLScript is a weakly typed language. While WMLScript does not support the creation of new objects via object-oriented programming, it does provide six pre-built libraries that aid in the handling of many common tasks.The operators and expressions supported by WMLScript are vir- tually identical to those in the JavaScript.
An example of WMLScript code is presented below: Random.ws extern function randomo { var one; Lang.seed(14); one = Lang.random(5) + 1; var variables = "one=" + one; var u = "random.wml"; WMLBrowser.setVar("one",one); WMLBrowser.go(u);
47 4.2 Design by Synthesis of Technologies
The design shown in Figure 4.2 is a client-server model used to develop the application. With this application, it is possible for a user to check the temperature of a remote location using a cell phone. The client is a Samsung cell phone and the carrier is Sprint PCS. The WAP gateway is pro- vided by Phone.com. The server is a computer at the Auto-ID Center. Most of the implementation was done on the server side, where standards are prevalent. There is no standardization yet on cli- ent-side cell phones. So, no specific applications were developed on the client side.
4.2.1 PML-to-WML Conversion
Consider the following PML file below. The software code converts this PML file into a direc- tory structure that contains WML cards. In practice, however, PML-to-WML conversion can also be specified by an XSL1 template [5] and implemented by a standard XSL processor. XSL imple- ments transformation by example i.e. a pattern matching template, and not just by program logic. Section 3.2.9 briefly describes XSL.
Consider the PML file shown below. '
WAP/WMIL HTTP
WAP Gateway Server Device
Wired - -- - - Wireless Wired or Wireless
I Figure 4.2: Overview of System
1. Refer Section 3.2.9
48 Detergent
Detergent.wml Td
------
Tide.wmi Directions
a - _ b b is contained in a Directions.wml a ...... b b is inherited from a
StockKeepingUnit.wml:
Tide.wml
Figure 4.3 schematically displays the mapping of the PML file above, to the WML card struc- ture. In the schematic we have distinguished between containership and inheritance, which are concepts described in object-oriented schema [22]. The display on the Nokia WAP emulator of the WML file corresponding to the above PML file is shown in Figure 4.4.
Figure 4.4: Nokia cell phone emulator displaying Tide.wml
49 The algorithm works by parsing the PML file in text format and recursively calling itself whenever a tag is encountered. The text encountered within a tag is placed automatically within the appropriate card. The pseudocode is listed below:
void transform (parentPMLTag) { while (parser has not reached 'end of file') if (closing parentPMLTag is parsed) { then return; else { if (opening childPMLTag is parsed) transform (childPMLTag); if (plainText is parsed), then write plainText in file corresponding to parentPMLTag;
To analyze this algorithm, let T(n) be the asymptotic running time of the algorithm for an XML file containing n tags. Then, the following recursion holds.
T(n) = T(n-1) + C where C=numerical constant (4.1) Working out this recursion, yields T(n)=O(n) time where n is the number of XML tags in the file. Hence, the asymptotic running time of this algorithm is linear with respect to the number of tags.
4.2.2 Server and ServIets
We used Java Servlet Development Kit 1.2 to develop servlets [31], [32]. This kit also includes a lightweight Java server. The functions performed by various servlets are: - requesting the temperature from a DS1620 temperature sensor via a BASIC Stamp microprocessor. " querying an XML database with XQL and returning the result to the client. - serving WML documents. In Appendix D, we have listed the servlet directory structure and the server configuration file.
4.2.3 BASIC Stamp and DS1620
We chose the BASIC Stamp II [33] as a controller because it is simple to program and ade- quate for the task. To program BASIC Stamp II, one has to connect it to the serial port of an IBM PC-compatible computer, type the code in the editor software, and download the program onto the Stamp. In a commercial application, the main controller can run on the host computer itself. The BASIC Stamp II is illustrated in Figure 4.5.
BASIC Stamp II runs PBASIC programs. The BASIC Stamp II contains 16 I/O pins and two synchronous serial pins, holds 500 to 600 instructions, and executes an average of 4000 instruc- tions/sec. The I/O pins can be used to directly interface with TTL voltage level devices, such as buttons, LEDs, speakers, potentiometers, and shift registers. And with just a few extra compo- nents, these I/O pins can be connected to non-TTL voltage devices, such as RS-232 networks, relays, solenoids, and other high current/voltage devices.
50 5 volt EEPROM regulator
20 Mhz Interpreter resonator Chip Figure 4.5: BASIC Stamp II
The BASIC Stamp II consists of a 5-volt regulator, resonator, serial EEPROM, and PBASIC interpreter. A tokenized PBASIC program is stored in the non-volatile serial EEPROM, which is read from and written to by the interpreter chip. This interpreter chip fetches the instructions one at a time and performs the appropriate operation on the [/0 pins or internal structures within the interpreter. Because the PBASIC program is stored in an EEPROM, it may be programmed and reprogrammed almost endlessly, without the need to first erase the memory, as with many micro- controllers.
The DS1620 is a digital thermometer that provides a 9-bit temperature reading indicating the temperature of the device [34]. It can also act as a thermostat with three thermostatic alarm out- puts, Thigh, Tiow, and Tcom. It measures temperature from -55*C to +125'C in 0.5'C increments. Data is input and output via a 3-wire serial interface (CLK, DQ, RST). It converts temperature to digital word in at most one second.
We connected the Stamp to the serial port of the host computer and a program on the host que- ried the Stamp. Since the serial port operates at non-TTL voltage, a few modifications were required in the serial line input to the Stamp. The circuit diagram is listed in Figure 4.6. The switch is closed when the program has to be downloaded to the EEPROM. The PC serial port logic levels are -12V for logic 1 and +12V for logic 0. The Stamp logic levels are 5V for logic 1 and OV for logic 0, and the I/O pins can source and sink 20mA. Hence, a resistor is needed between Tx and Pin6, which is Serialln. Its value is [12-(-12)-(5-0)]/lmA - 22Kohm resistor. The lKohm resistor is not strictly necessary, but it restricts the amount of current to a safe value when both the Stamp and the DS 1620 try to drive the data line DQ at the same time. The 0. luF capacitor shorts any high frequency spikes in VDD and protects the DS 1620.
4.2.4 WAP Gateway
We used the Ericsson Gateway (IP address 195.58.110.201) for development and testing our code with the cell phone emulators, which were provided free by Ericsson and Nokia. Later when our code was perfected, we tested successfully the same code on Sprint PCS cell phone. The Sprint network uses the Phone.com Gateway (IP address 208.18.146.75).
51 PIS El 7 1 P11 2Zi .9 ~Pt i4~RS
P2~ l
22Kohm
. Kohm El -8V-- DD GND CLK/CONV : T 2 HIGH DS1620 O.luF RST [3 ]TLOW GNE 8-pin DIP and SOIC
Figure 4.6: Circuit diagram: BASIC Stamp and DS1620
4.3 Lessons Learned and Applications
What we have built is a framework for future applications that might use a multitude of sen- sors and actuators. This application can be extended: - to implement a complete user interface to a home-automation system. - to perform status checks on remote experiments and adjust set points. - to manipulate robots across time delays, which are longer than system time constants.
The software application may be further refined as a 'Delegate' [35]. The 'Delegate' can per- form the following types of functions: - performs tasks when requested by the supervisor - asks the supervisor before performing the task " performs the task and tells the supervisor later - automatically performs the task
52 Hence, the 'Delegate' is an information filter that can be pre-programmed to decide whether the supervisor should be informed about a certain event. Here, we distinguish between media information, which is currently available on a mobile interface, and physical world information, which the Auto-ID Center endeavors to deliver to a mobile platform. It is important to note that the limitations in screen size of hand-held devices ensures that wireless content providers do not pub- lish unnecessary text or graphics. This provides a basic information filter to the user. However, as screen displays improve, this first line of defence may crumble.
Sheridan identifies a spectrum of control modes, which range from manual control to supervi- sory control to fully automatic control [36]. Our application falls in the domain of a supervisory control application. Supervisory control means that one or more human operators are continually programming and receiving information from a computer that itself closes an autonomous control loop through artificial effectors and sensors to the controlled process or task environment.
Wireless interfaces to business data is adding value to the company's employees who are con- stantly on the move. Joshi has explained the improvements in supply chain performance by pro- viding the data from the point of sale to the factory [37]. AvantGo.com provides corporate and market data to the mobile employees of its corporate clients via the Palm network and also allows them to uplink data to the corporate database [38]. Foley describes how Auto-ID technology can be used in home automation [3]. Siemens Insta- bus describes a cellular phone interface to controlling home equipment [39]. Home Automation Association is the trade association of the home control industry and is committed to popularizing home automation systems [40]. The ePC data from RF readers in a remote locations can be obtained with assured Quality of Service (QoS) and time delay using real time protocols, such as RTP [41] and Tenet [42]. These protocols have been designed for multimedia transport.
53 54 Chapter 5: Conclusions
In this thesis we have described a framework for integrating physical objects with the Internet, and obtaining information about them anytime anywhere. We broadly classified our research into three layers, which are the Physical Object Layer, the Information Storage and Retrieval Layer, and the Wide Area Access Layer.
In the Physical Object Layer, our work elucidated how the Electronic Product Code (ePC) complements technologies, such as JiniTM and Bluetooth, for Resource Discovery of new Devices I in a Local Area Network (LAN). We compared the different possible numbering schemes of the ePC. We proposed the RSVP protocol among RF Tag Readers for tracking tagged Individual Inventory Items. A Device needs to tell the JiniTM lookup service only its ePC. The lookup service contacts the Device manufacturer's PML Server for the Physical Markup Language (PML) file of the Device via the Object Naming System (ONS). Therefore, the Device need not have a JiniTM chip that runs JiniTh (and Java) to actually be a part of a federation of JiniThm Devices. This reduces the cost of Jini t m-compatible Devices. The proposed RSVP protocol will be useful in applications which require information on the location and movement of a physical object, such as inventory tracking in a warehouse, and detec- tion of theft in progress in a retail store.
The information referenced by the ePC of a physical object is in PML format, the lingua franca for describing physical objects. In the Information Storage and Retrieval Layer, we investigated the implications of the XML data model because PML is based on XML. Our insight will be useful during the research required to define PML. Our practical implementation involved the use of XML and XQL, along with JiniTM, to develop a client-server software application, which tracks physical objects moving in a remote location. We came to the conclusion that XML is: - a format for data-exchange among distributed heterogeneous databases. Collaboration among various manufacturers will be necessary for its widespread applicability. - a facility to include meta-information in documents. When XML text documents are parsed, the relationships among elements have to be inter- preted by a mapping software, which maps the logical structure of the XML document into an effi- cient database system. Though XML is an abstract data model, a specific instance of an XML data model for a real problem may map conveniently to a currently implemented and efficient data model, such as the relational or the object-oriented. If there is impedance-mismatchin such a map- ping, it means that the relational or the object-oriented data model is not able to model the com- plexity of relationships in the real problem. XML format can be considered as a format to interface with an efficient database system. On the Internet, there are different types of database systems. If each of them provides an XML inter- face, the Internet can then be viewed as one very big distributed XML database.
1. Device is defined in Chapter 1
55 In the Wide Area Access Layer, we demonstrated that it is possible to access remote sensor data using a cell phone. Our application allows a user to access the temperature in a remote loca- tion using her WAP-enabled cell phone. We described our software that automatically converts PML to WML format for display on mobile devices. The asymptotic running time of this algo- rithm is linear with respect to the number of tags.
We described application domains which would benefit by integrating physical objects with the Internet and providing information on them anytime anywhere. The application domains include supply networks and 'smart' homes. In supply networks, it is possible to obtain real-time information on inventory items, resulting in more informed decisions by supply chain managers. It is also possible to deliver dynamic information on physical objects to concerned users, as in the example of the meat packaging factory. In 'smart' homes, the home computer will be able to obtain information on tagged objects in the house. It will be possible to perform automatic ordering of groceries. Our cell phone applica- tion can be extended to implement a complete user interface to a home-automation system, and to perform status checks on remote activities.
Before it is possible to implement a viable infrastructure for automatic identification of physi- cal objects, various issues should be resolved by further research [43]. For instance, it will be nec- essary for the cost of each RF Tag to drop to a few cents before this system will be attractive to manufacturers. Anti-collision technology for RF Readers must develop further so that a single RF Reader can quickly resolve responses from multiple RF Tags. The available systems of RF Reader and Tag are not standardized. They differ in technology, operating costs and set-up costs, and therefore, the promise of widespread deployment. The ePC needs to be allocated to every manufacture, and the ONS will be more robust if it is distributed. The PML requires a careful analysis of the data model appropriate for physical objects. It also requires subsequent collaboration among manufacturers to choose XML tags. The issues of privilege of control of the PML file must be resolved.
This thesis dealt with various issues on integrating physical objects with the Internet. We suc- ceeded in demonstrating an over-arching technological framework to implement a viable system.
56 Appendix A : Acronyms A API: Application Programming Interface
B BASIC: Beginner's All-purpose Symbolic Instruction Code
C CAD: Computer Aided Design CAE: Computer Aided Engineering CASE: Computer Aided Software Engineering CDATA: Character Data CDMA: Code Division Multiple Access CDPD: Cellular Digital Packet Data CMS: Content Management System CSS: Cascade Stylesheet Language
D DataTAC: Data Total Access Communications, Motorola packet data radio system DECT: Digital Enhanced Cordless Telecommunications DISC: Distributed Intelligent Systems Center DOM: Document Object Model DTD: Document Type Definition
E ePC: Electronic Product Code E-R: Entity-Relationship (data model)
F Fab: Fabrication facility FLEX: Flexible wide area paging protocol
G GSM: Global System for Mobile communication
H HTML: Hyper Text Markup Language
ID: Identity iDEN: integrated Digital Enhanced Network IP: Internet Protocol
L LAN: Local Area Network
57 M Mobitex: a packet switched data network technology from Ericsson
0 ONS: Object Naming System
P PBASIC: Parallax BASIC PCDATA: Parsed Character Data PDC: Personal Digital Cellular, a Japanese standard operating on 800 MHz and 1500 MHz PHS: Personal Handy-phone System PML: Physical Markup Language
Q QoS: Quality of Service
R ReFLEX: a narrowband PCS technology for two-way text messaging by Motorola RF: Radio Frequency RFC: Request For Comment RTP: Real-time Transport Protocol
S SAX: Simple API for XML SGML: Standard Generalized Markup Language
T TCP: Transmission Control Protocol TDMA: Time Division Multiple Access TETRA: Terrestrial Trunked Radio Access
U UCC: Uniform Code Council, Inc. UPC: Universal Product Code URL: Uniform Resource Locator
W WAP: Wireless Application Protocol WML: Wireless Markup Language WMLScript: Wireless Markup Language Script W3C: World Wide Web Consortium
X XML: eXtensible Markup Language XQL: XML Query Language XSL: eXtensible Stylesheet Language
58 Appendix B : Generations of Database Systems The generations of database systems are as follows:
1. File systems such as ISAM and VSAM.
2. Hierarchical database systems such as IMS and System 2000.
3. CODASYL database systems such as IDS, TOTAL, ADABAS, IDMS, etc. The second and third generation systems allowed the sharing of an integrated database among many users within an application environment.
4. Relational database system This was designed to address the problems of impedance mismatch, lack of data inde- pendence, and tedious navigational access to the database in the second and third gen- eration systems. Relational database systems introduced the notion of a declarative query
59 60 Appendix C : Use of XML/XQL The following example has been included from http://www.w3.org/TandS/QL/QL98/pp/ maier.html because it is very instructive about the use of XML and XQL. It is a very simple exam- ple of the way, in which XML and XQL can be used. Consider the problem of trying to find the best prices on cars that ranked in the top 10 of the NHSC crash-safety tests. To produce this information, it is necessary to combine information from a rankings document from NHSC, with documents from different auto dealers and brokers listing their prices. Suppose that we are interested in finding out if there are models in the top 10 of the rankings for sale under $30,000. The NHSC provides XML data of the form
while the dealers and brokers publish information in the form
Selection and Extraction: For our query, we want to select and extract
61 Reduction: For the
A sample of records, which are retrieved, are shown below:
Combination: We want our query to connect
Restructuring: There are many ways to structure the resulting information. One possibility is as a collection of
62 Appendix D : Serviet program The directory structure of the web server directory is shown in Figure D. 1
web-server directory
default.cfg startserver.bat WMLGetTempWStamp webpagues stopserver.bat
mapping.properti es in dex.html Web-INF mime.properties Web-INF webapp.propertie s servlets.propertie s mapping.properties mime.properties servlets webapp.properties servlets.properties WMLGetTempWStamp.class MyTermTestForStamp3.class TermRcvTask. class TermSndTask.class Figure D.1: Directory structure of server
# Default configuration file for Java server server.port=80 server.hostname= server.inet= server.docbase=webpages server. tempdir=tmp # All sections of the server's namespace are defined in terms of a 'webapp'. There are two attributes that # define a webapp, 1) a mapping of where the webapp is placed into the namespace of the server and 2) # base of the webapp. The base can be composed of a simple string as shown below which indicates a # file relative to the current working directory (the directory in which the server was started) or can be a # full URL. server.webapp.WMLGetTempWStamp.mapping=/WMLGetTempWStamp server.webapp.WMLGetTempWStamp.docbase=WMLGetTempWStamp
63 64 References [1] MIT Auto-ID Center, [http://auto-id.mit.edu].
[2] Lester Thurow, Building Wealth: The New Rules for Individuals, Companies, and Nations in a Knowledge-Based Economy, New York Harper Business, 1999.
[3] Joseph T Foley, An Infrastructurefor ElectromechanicalAppliances on the Internet, M.Eng. Thesis, MIT, 1999.
[4] WAPForum, [http://www.wapforum.org/].
[5] World Wide Web Consortium, [http://w3c.org].
[6] Uniform Code Council, [http://www.uc-council.org/].
[7] David L Brock, "Speech to MIT Distributed Intelligent Systems Center", January 2000.
[8] Sun Microsystems, [http://www.sun..com].
[9] Bluetooth Special Interest Group, [http://www.bluetooth.com/.
[10] GLOBIT, Dolivostr, 15 D-64293 Darmstadt Germany [http://www.globit.com/infonyte.htm].
[11] Motorola, Inc., "Bistatix tags", [http://www.motorola.conLMPS/Indala/bistatix.htm].
[12] Worthdata, "Bar code basics", [http://www.barcodehq.com/], 1997.
[13] Sanjay E Sarma, Niranjan Kundapur, "Discussion", May 2000.
[14] Joseph T Foley, Sanjay E Sarma, Daniel Engels, Niranjan Kundapur, "Discussion", March 1999.
[15] RFC 793 Transmission Control Protocol, 1981.
[16] RFC 791 Internet Protocol, 1981.
[17] Institute for Simulation and Training, Enumeration and bit-encoded values for use with proto- cols for DistributedInteractive Simulation Applications, University of Central Florida, Docu- ment IST-CR-93-02
[18] Gene Franklin, David J Powell, Michael L Workman, Digital Control of Dynamic Systems, Ed.3, Addison-Wesley, 1998.
[19] Tom Cormen, Charles Leiserson, Ronald Rivest, Introduction to Algorithms, MIT Press, 1991.
[20] Network Working Group, Standards Track, RFC 2205, RSVP - Version 1 Functional Specifi- cation, and supplemented by RFC 2205 to RFC 2209
[21] Andrew S Tanenbaum, Computer Networks, Ed.3, Prentice Hall, 1999.
[22] Robert Lafore, The Waite Group's Object-orientedProgramming in C++, 1998.
[23] Procter & Gamble, [http://www.pg.com/l].
[24] Bert Bos, "XML in 10 points", [http://www.w3.org/XML/1999/XML-in-I0-points], 1999.
65 [25] Ronald Bourret, "XML and Databases", Technical University of Darmstadt, [http:// www.informatik.tu-darmstadt.de/DVSI/staff/bourret/xml/XMLAndDatabases.htm], 1999.
[26] Abraham Silberschatz, Henry Korth, Sudarshan S, Database System Concepts, Ed.3, McGraw-Hill, 1999.
[27] Won Kim, Introduction to Object-OrientedDatabases, The MIT Press, 1990.
[28] Members of XML-dev mailing list, "SAX: Simple API for XML", [http://www.meggin- son.com/SAX/].
[29] Jon Bosak, Sun Microsystems, Inc., "XML, Java, and the future of the Web", [http://meta- lab.unc.edu/pub/sun-info/standards/xml/why/xmlapps.htm].
[30] Jonathan Robie, "The Design of XQL", Texcel Research, [http://www.texcel.no/whitepapers/ xql-design.html].
[31] Sun Microsystems, Inc., "Java web page", [http://java.sun.com/].
[32] David Flanagan, Java in a Nutshell, Ed.2, O'Reilly, 1997.
[33] Parallax, Inc., 599 Menlo Drive, Suite 100 Rocklin, California 95765, USA, [http://www.par- allaxinc.com/].
[34] Dallas Semiconductor Thermal Management Products, [http://www.dalsemi.com/Prodinfo/ Thermal/thermal.html#l 722].
[35] Kevin Ashton, Niranjan Kundapur, "Discussion", March 6, 2000.
[36] Thomas B Sheridan, Telerobotics, Automation, and Human Supervisory Control, The MIT Press, 1992.
[37] Yogesh V Joshi, Information Visibility and its Effect on Supply Chain Dynamics, S.M. thesis, MIT, 2000.
[38] AvantGo, Inc., [http://www.avantgo.com/].
[39] Siemen's Instabus home automation system, [http://www.ad.siemens.de/intelligent-home/ html_76/home/index_76.htm].
[40] Home Automation Association, [http://www.homeautomation.org/], 1444 I Street, NW, Suite 700, Washington, DC 20005, USA.
[41] RFC 1889 RTP: A Transport Protocol for Real-Time Applications.
[42] Anindo Banerjea, Domenico Ferrari, Bruce Mah, Mark Moran, Dinesh Verma, Hui Zhang, The Tenet Real-Time Protocol Suite: Design, Implementation, and Experiences, IEEE ACM Transactions on Networking, 4(l):1-10, February 1996.
[43] Jocelyn 'Bink' Tait, Niranjan Kundapur, "Discussion", May 2000.
66