This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
research:rfid [2010/07/27 17:08] kpinte |
research:rfid [2011/09/12 18:50] kpinte |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Software Abstractions for the Development of Mobile RFID-enabled Applications ====== | ||
- | // | ||
- | ==== RFID-enabled Library ==== | ||
- | The RFID-enabled library is a //mobile RFID-enabled application// | ||
- | |||
- | == Towards naturally expressing RFID applications == | ||
- | |||
- | Developing such mobile RFID-enabled applications with traditional software abstractions is a daunting task given the extreme volatility of connections to RFID tags. Simple repositioning of the mobile (reader) device, interference, | ||
- | |||
- | We even go one step further, by representing RFID-tagged objects as full-blown software objects. State-of-the-art RFID applications merely use RFID tags as digital barcodes and remain oblivious to the enormous potential of RFID technology in ubiquitous computing scenarios. For example, they do not use the writable memory on RFID tags to store contextual information. | ||
- | |||
- | Using the abstractions we present further on this page, programming RFID applications becomes more natural as application logic can be directly expressed in terms of the presence or absence of software objects representing physical items. Building on the [[research: | ||
- | |||
- | In short, we consider RFID tags as the bridge between the physical and digital world. They effectively store digital stand-ins for real world items. | ||
- | |||
- | == Demo == | ||
- | |||
- | The movies below show a small prototype showing discovery of books on a shelf and a user adding a comment to a book. | ||
- | |||
- | < | ||
- | <object width=" | ||
- | </ | ||
- | |||
- | < | ||
- | <object width=" | ||
- | </ | ||
- | |||
- | ==== Requirements ==== | ||
- | To align physical objects tagged with writable RFID tags as true mutable software objects we model these objects as proxy objects acting as stand-ins for physical objects. For this model to be applicable to mobile RFID- enabled applications, | ||
- | |||
- | - **Addressing physical objects** RFID communication is based on broad- casting a signal. However, to be able to associate a software object with one particular physical object, it is necessary to address a single designated physical object. | ||
- | - **Storing application-specific data on RFID tags** Since mobile RFID- enabled applications do not rely on a backend database, the data on the RFID tags should be self-contained and stored on the writable memory of the tags. | ||
- | - **Reactivity to appearing and disappearing objects** It is necessary to observe the connection, reconnection and disconnection of RFID tags to keep the proxy objects synchronized with their physical counterparts. Differen- tiating between connection and reconnection is important to preserve the identity of the proxy object. Furthermore, | ||
- | - **Asynchronous communication** To hide latency and keep applications responsive, communication with proxy objects representing physical objects should happen asynchronously. Blocking communication will freeze the ap- plication as soon as one physical object is unreachable. | ||
- | - **Fault-tolerant communication** Treating communication failures as the rule instead of the exception allows applications to deal with temporary unavailability of the physical objects and makes them resilient to failures. For example, read/write operations frequently fail due hardware phenomena. | ||
- | |||
- | ==== Software Abstractions ==== | ||
- | |||
- | == RFID event loop == | ||
- | |||
- | == RFID tags as mutable proxy objects == | ||
- | |||
- | < | ||
- | deftype Book; | ||
- | |||
- | def aBook := object: { | ||
- | def ISBN := 123; | ||
- | def title := "My Book"; | ||
- | def reviews := Vector.new(); | ||
- | |||
- | def setTitle(newTitle)@Mutator { | ||
- | title := newTitle; | ||
- | }; | ||
- | |||
- | def addReview(review)@Mutator { | ||
- | reviews.add(review); | ||
- | }; | ||
- | } taggedAs: Book; | ||
- | </ | ||
- | |||
- | < | ||
- | whenever: Book discovered: { |book| | ||
- | whenever: book disconnected: | ||
- | whenever: book reconnected: | ||
- | }; | ||
- | </ | ||
- | |||
- | < | ||
- | when: book< | ||
- | system.println(title) | ||
- | }; | ||
- | system.println(" | ||
- | </ | ||
- | |||
- | |||
- | < | ||
- | def myReview := "not suitable for beginners"; | ||
- | when: book< | ||
- | // message processed successfully | ||
- | } catch: TimeoutException using: { |e| | ||
- | // message timed out | ||
- | }; | ||
- | </ | ||
- | |||
- | == Ambient References == | ||
- | |||
- | < | ||
- | def books := ambient: Book; | ||
- | def computerScienceBooks := ambient: Book where: { |b| | ||
- | b.category == " | ||
- | }; | ||
- | </ | ||
- | |||
- | < | ||
- | def shelfFuture := computerScienceBooks< | ||
- | when: shelfFuture becomes: { |shelf| | ||
- | system.println(" | ||
- | }; | ||
- | |||
- | computerScienceBooks< | ||
- | </ | ||
- | |||
- | == Multiway References == | ||
- | |||
- | |||
- | == Sample Application == | ||
- | |||
- | < | ||
- | def books := ambient: Book; | ||
- | whenEach: books< | ||
- | GUI.addBookInfoAndReferenceToList(infoAndRef); | ||
- | }; | ||
- | whenever: Book discovered: { |book| | ||
- | whenever: book disconnected: | ||
- | </ | ||
- | |||
- | < | ||
- | def addReviewToBook(book, | ||
- | when: book< | ||
- | showOkDialog(" | ||
- | } catch: TimeoutException using: {|exc| | ||
- | showWarningDialog(" | ||
- | }; | ||
- | }; | ||
- | </ | ||
- | |||
- | ==== Conclusions ==== | ||
- | |||
- | By implementing an example mobile RFID-enabled application, | ||
- | - **Addressing physical objects** The implementation of the application shows that mobile RFID-enabled applications can be written in an object-oriented fashion, where application-level proxy objects uniquely represent physical objects in one’s physical environment. | ||
- | - **Storing application-specific data on RFID tags** The data needed to con- struct these proxy objects is stored on the RFID tags themselves. | ||
- | - **Reactivity to appearing and disappearing objects** Application logic is ex- pressed in terms of reactions to changes in the physical environment by relying on a number of expressive abstractions that are integrated into a communicating event loops framework. | ||
- | - **Asynchronous communication** Interacting with physical objects is achieved by using the message passing metaphor on the proxy objects, by means of asynchronous message passing and asynchronous signaling of return values. | ||
- | - **Fault-tolerant communication** Communication failures are considered the rule rather than the exception. Failures that must be considered permanent are detected and raise the appropriate exceptions. | ||
- | |||
- | |||
- | ==== Further Reading ==== | ||
- | * Distributed Object-Oriented Programming with RFID Technology. Andoni Lombide Carreton, Kevin Pinte, Wolfgang De Meuter. In Lecture Notes in Computer Science, vol. 6115, Eliassen F, Kapitza R (eds.), 2010; 56–69. [{{: | ||
- | |