Rapid Prototyping for Pervasive Applications - FTP Directory Listing

PROGRAMMING LANGUAGES

Rapid Prototyping for Pervasive Applications VisualRDK is a high-level programming language for prototyping pervasive applications. Context is tightly integrated into the language itself, so developers can attach functionality to locations, persons, or situations instead of the device.

P

ervasive computing appliances range from consumer devices over embedded sensor boards to PCs and large-scale context servers. Because these devices vary tremendously in their capabilities, application developers must create different programming models for every class of device. This makes rapid prototyping infeasible as soon as more than one class of devices is involved. Rapid prototyping therefore requires a programming model that hides the environment’s heterogeneity. Torben Weis and Mirko Knoll Pervasive applications are University of Stuttgart inherently distributed. Logical Andreas Ulbrich and Gero Mühl control flow jumps between Berlin University of Technology sensors, context servers, PDAs, and any other kind of networkAlexander Brändle ing appliance. The control flow Microsoft Research Cambridge is extremely difficult to follow using classical debugging tools because a debugger is attached to a single process running on a single device. To circumvent this problem, we’ve developed the Visual Robotic Development Kit (VisualRDK) that can generate two implementations from one source: a prototype version and a debug version. The prototype version is truly distributed and so, with respect to its architec76

PERVASIVE computing

ture, close to the final product. However, it’s hard to debug. The debug version is centralized—that is, the entire application logic executes on the developer’s PC and all involved devices are remote controlled. Although this isn’t useful in a product, it simplifies debugging.

Properties of pervasive applications Pervasive computing applications are compositional—that is, they combine different components’ functionality. A component can be a device such as a TV, PDA, or doorbell, or a software service such as a browser or media playback. Pervasive applications can build on an infrastructure or ad hoc network. Our tool focuses on applications that rely on an infrastructure. Other approaches, such as the Pervasive Component System (PCOM; see the sidebar “Related Work in Pervasive Computing Tool Support” on pages 82–83), are better suited for ad hoc scenarios. Context is an important concept in pervasive computing applications. It tells us about spaces (living room or kitchen, for example), situations (such as meeting or shopping), and the location of persons and devices. Pervasive applications must adapt their behavior to the dynamic context in which they execute. Thus, we want to bind functionality to situations, persons (follow-me

Published by the IEEE Computer Society ■ 1536-1268/07/$25.00 © 2007 IEEE

wait Playing

VisualRDK is a pervasive computing counterpart to languages such as VisualBasic. Its target audience is professional developers who want to prototype an application and hobby programmers who want to customize their environment. We don’t especially target end-user programming, because the tool is still too difficult and too powerful for computer novices. For hobby programmers, VisualRDK must be able to support two classes of pervasive applications: • Automation applications react to events and context changes occurring in the real world. These applications control appliances ranging from programmable picture frames to media center PCs and include home and APRIL–JUNE 2007

lamp M1: Off media volume 46

Suspend Reset

select case Motion

case timeout = 20

lamp M1: On

light M1: Off

wait Stopped, Paused emit Reset lamp M1: On media volume mute

«

A programming language for pervasive computing

emit Suspend

Suspend Reset

«

applications), or locations (for tourist information, for example). You can obtain context by querying a context server or directly querying sensors. Our tools support both approaches. Processing in pervasive computing applications is event driven and asynchronous.1 Components emit events, such as starting a DVD playback. A context server can also emit events—for example, when a person enters a room. Event handling in pervasive applications is asynchronous because the physical world isn’t synchronized with our applications (that is, the physical world doesn’t wait until the software finishes its event handling). Asynchronous events are especially useful when software has to support real-time constraints.2 In this way, pervasive applications differ from common GUI frameworks (such as Qt and .NET), which use synchronous callbacks. If your GUI window is about to close, it remains open until you’ve processed the close event—that is, until the callback returns. A real-world window won’t wait for any computer action before closing; it just closes.

Light

«

DVD

«

Figure 1. Example application using VisualRDK.

office automation, programmable remote controls, follow-me applications, and spatial-information systems. • Communication applications let users communicate with each other. Here, users directly trigger actions via a GUI, and the context server determines communication partners and their roles. An example is a chat application that lists on your PDA all your friends or colleagues who are near your current location. Software that supports lectures or meetings also belongs to this application class. VisualRDK can’t realize some other classes of pervasive applications. For example, smart shop and smart factory applications have complex logic and must be integrated with enterprise software. Because for these applications the problem of dealing with the context server is comparably small, VisualRDK could only remove a small fraction of the complexity. However, VisualRDK and its source code generator can still be useful as a rapid prototyping tool. User interface In VisualRDK, developers create pro-

grams by dragging components and application logic commands from the icon bar on the editor. Developers can further configure commands and components via property dialogs. Visual Pattern Recognition,3 HIVISUAL,4 and similar projects use graphical primitives such as position, inclusion, overlap, color, and icons to express application logic. A common argument against such languages is the Deutsch limit, which states, “You cannot have more than 50 visual primitives on the screen at the same time.” If the programming primitives rely heavily on position, inclusion, and overlap, you must take care to ensure the language’s scalability. The number of textual primitives that will fit on a screen is limited, too. However, users can read text line by line. Thus, screen size isn’t a limiting factor for text-based languages. VisualRDK’s graphical notation (see figure 1) is close to the structure of textual languages. You can easily follow the program flow by scrolling down—that is, reading it line by line. Programs with more than 500 programming primitives weren’t a problem for our toolkit. Constructs that become too large appear with a double arrow in PERVASIVE computing

77

PROGRAMMING LANGUAGES

Figure 2. Using VisualRDK to configure the available components.

Process Function Hardware Location

components of the same type (for example, two smart phones), you must refer to instances of components via a unique ID (for example, IP address), location (DVD player in the living room), or situation (screen next to me). This might require querying a context server, as we discuss in the next section.

Ink

Mouse

Eraser

their upper-right corner (for example, the processes and the media command in figure 1). This lets users collapse the constructs to save screen space. Collapsed processes provide a thumbnail of their workflow, while all other constructs collapse to small boxes titled “media” for a media command or “loop” for a collapsed loop. Finally, our editor features automatic and canonical diagram layout for concise presentation. Figure 1 shows a simple example application. The application’s objective is to switch to cinema mode when DVD playback starts and return to normal mode when the DVD ends. When there’s no playback, the lights should be on as long as someone is present. When playback starts, the DVD process turns off the lights and increases the volume. When the playback stops or pauses, the lights go on again and the process starts over. The Light process keeps the light switched on as long as something is moving. Because someone might move during DVD playback, causing the lights to go on, the DVD 78

PERVASIVE computing

Run

process suspends the Light process during playback. To do this, the DVD process sends a Suspend signal to the Light process. Components A component represents a piece of hardware or software and has a location in the physical world. Components can be prefabricated. We intentionally don’t provide means for defining new components. Pervasive computing’s main benefit is that it glues together functionality that’s already available. If you want to develop a new component (for example, a speech recognizer or motion tracker), you’re probably better off using existing object-oriented tools. In VisualRDK, you can import components by simply dragging them from a toolbar on the editor window (see figure 2). A component introduces a set of events and commands. For example, a media center PC emits an event when it starts DVD playback. Commands such as start playback or adjust volume control this component. If your application requires multiple

Context Context tells us about location, situations, nearby persons, and available components. In VisualRDK, you can easily attach functionality to a special location (for example, a living room) or a group of locations (for example, all office rooms). Therefore, VisualRDK must know which locations exist and which components are available where. Either you create a static location model by arranging components on a floor plan using drag-and-drop, or you could point VisualRDK to a context server, which has a location model, using a corresponding plug-in. This plug-in tells VisualRDK which location types (for example, room or building) are known, which situations (for example, meeting or shopping) can be detected, and which kind of mobile devices or persons can be tracked. Furthermore, it emits events when a person moves or a situation starts or ends. Suppose you want to write a script that turns on the lights in a room when someone enters. If you want this to work in the living room only, you can simply hard-wire the application logic with sensors and lights in the living room. If you want it to work for any room, you simply attach the Light process to the location group Room, as figure 3 shows. You then select Run in every room in the process’s property dialog. For this to work, VisualRDK must be able to determine all rooms that feature the required devices—that is, the motion sensor and controllable lamp. This example uses anonymous components, meaning that the concrete instance (for example, a lamp in the living room or www.computer.org/pervasive

«

Light @ Room X select case timeout = 20

lamp X: On

light X: Off

Process Hardware

TV Follow Me @ Person statement ch := 1 select case RoomChanged find any TV x in Room

Figure 3. A process group for an application that controls the lights in one or more rooms.

APRIL–JUNE 2007

x !+ null ? set channel x to ch

Ink

Mouse

Eraser

Run

Figure 4. A simple follow-me application. As you walk from one room to the next, your TV (if the current room contains one) switches to the channel selected in the previous room.

Process1 emit Signal Signal

Process2

«

in the kitchen) depends on the context. Upon a process’s execution, VisualRDK detects which anonymous components are used and determines their context-specific counterparts via the location model. In the process group in figure 3, VisualRDK will find out that the process requires one motion sensor and one controllable lamp per room—that is, it uses two anonymous components. It ignores rooms without the required components. You can deal with context explicitly as well as implicitly. Context server plugins can supply find any and find all commands, which you can use to search for a certain entity type (for example, person, display, or restaurant). Furthermore, your query can specify attributes (for example, resolution = “1280  800”) and location. By combining implicit and explicit context handling, you can implement a large range of applications. You can build a tourist information service by attaching a process to a popular tourist location and using find all to query for persons nearby. You also can attach a process to a situation, such as a meeting. When the context server detects a meeting, VisualRDK starts your process, and you can search for a PowerPoint-capable device in the meeting room. Attaching a process to a person, as figure 4 shows, lets you construct follow-me applications. Whenever the context server emits a roomchanged event for your process (that is, the person moved), you find a nearby TV

case ChannelChanged statement ch := ChannelChanged.Current

Receiver

«

case Motion

wait Receiver

Figure 5. Processes and interprocess communication.

using find any and switch to the preferred channel. The application in figure 4 features a GUI implemented in C#. The GUI is connected via events (that is, ChannelChanged) with the VisualRDK application logic. VisualRDK doesn’t make many assumptions about context type. This is mainly up to the context server plug-in. You wouldn’t be able to implement a context server plug-in in a single day. However, you could use such a plug-in— once one is developed or standardized— for a wide variety of applications. Events and processing A pervasive application’s behavior consists mostly of waiting for one or more events, doing some processing,

controlling components, and waiting again. Because multiple events can occur in parallel, our language builds on the concept of concurrent processes and interprocess communication. Figure 5 shows the notation for two processes: Process1 defines a signal, and Process2 defines a signal receiver. A process contains a control flow, which orchestrates events and commands. VisualRDK defines some fundamental commands: • The statement command (see figure 4) assigns an expression’s value to a local variable. Variables don’t have to be declared because their type will be determined through type inference at compile time. PERVASIVE computing

79

PROGRAMMING LANGUAGES

wait Receiver1

wait timeout = 500

wait s.Temperature Receiver1> 23?

let a:= a*2

(a) wait Room.Leave

let a:=2

(b)

split wait timeout = 600

wait Blinds.Down

light L1: Off (b)

(c)

wait Door.Locked

DVD Start

Figure 6. VisualRDK commands: (a) the wait command pauses the process, (b) the select command lets you wait for multiple events, and (c) the split command enables parallelism.

• The wait command pauses the process until specified events, conditions, or time-outs occur, as figure 6a illustrates. • The emit command sends out a signal on a sender (Process1 in figure 5). All connected receivers can wait for the emitted signal. Other researchers have successfully used a similar approach in the area of real-time event-driven systems.2 • The select command (shown in figure 6b) pauses the process until the condition of a wait command becomes true. This command implies an Or semantic. Depending on the event, select takes a different branch. A common usage pattern for select is to wait for several events or a time-out, because timeouts often require additional actions. • The split command (figure 6c) executes threads in parallel. It implies a join at the end—that is, it completes only when all its branches complete. Using wait in several branches of a split implies And semantics for events. You can use this to synchronize the completion of more than one activity. Using combinations of wait, select, and split, the application can wait for every possible conjunction and disjunction of events, conditions, and timeouts. VisualRDK provides easy-to-use constructs for com80

let a:=1

loop (a)

select wait Room.Enter

1