Support for User Control in Palcom Boris Magnusson Lund University Dept of Computer Science Sweden +46-46-2228044
[email protected] ABSTRACT In this position paper we give an outline of the Palcom platform for pervasive computing and some of the design issues. With this as a background we initiate a discussion of the balance between the user being in control, and the system behaving in a helpful way.
Categories and Subject Descriptors D.2.11 D.2.11 [Software Architectures]: Patterns – assemblies.
General Terms Experimentation,, Human Factors, Languages.
Keywords Pervasive systems, Palpable computing, middleware, Assemblies. 1.INTRODUCTION Pervasive computing put focus on the emerging situation where communicating devices and services needs to be put together in flexible ways. In heterogeneous mobile networks, devices come and go. The combined behavior needs to adjust to the changing situation, and the availability of services. The behavior frequently needs to be changed in order to include new, previously unknown, types of devices and services. This kind of situations appears in your pockets, including mobile phones, mp3-players, cameras, etc., in your home including audio-video equipment etc., and in professional settings such as in healthcare and industry automation, to take just a few examples. The challenges grow with the spreading use of an increasing number of such interconnected devices so visionary predicted by Weiser [1]. Palcom is a research prototype of a middleware for pervasive systems trying to address some of the issues in building applications out of mobile devices in a changing environment. We build prototypes in order to evaluate ideas in practical settings in an iterative way. Some of our motivation come from cooperation with local companies such as Sony Ericsson, AXIS, and the university hospital. The roots of the work come from the EU-project Palcom which resulted in an open source platform available for download Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference’10, Month 1–2, 2010, City, State, Country. Copyright 2010 ACM 1-58113-000-0/00/0010…$10.00.
[2]. It has been used for several large applications. For example in healthcare, emergency rescue and home applications. The original reference implementation of Palcom was subject to many compromises, changes during the project, and suffer from a somewhat degraded architecture. The platform has now been reimplemented, guided by insights from the first version. It is based on the same underlying model for pervasive systems, still compatible with the original framework, and is now ready for an extended scope. One of the new technical application areas we are working with is real-time control. On the softer aspects of pervasive computing we will look into how we can move towards more automation of user tasks while still providing understandability for the user. 2.PALPABILITY AND SCRUTABILITY We here focus on scrutability from the perspective of how to enable end-users to exercise control of a collection of connected equipment put together for a purpose. In order to control, a user need to understand aspects as: what equipment is included, how the parts are connected, how and if the parts work, the state of each part etc. In the Palcom project the conceptual framework of Palpability [3] was formed by considering the following six challenges for palpable computing - Trying to find a balance between: Visible versus Invisible, Scalability versus Understandability, Construction versus De-construction, Heterogeneity versus Coherence, Change versus Stability, Automation versus User control. From a scrutability perspective the last challenge is central: in order to provide User control, without burden the user with repeated tedious tasks, some form of Automation is needed, but to much automation can hamper user control. Understandability is essential for end users in order to exercise control, and one challenge is to offer general concepts for pervasive systems that make sense for end users. Heterogeneity in terms of both network technologies and application protocols needs to be bridged in order to offer Stability, so a user can be in control when the user, the network, or the devices move or change. Visibility, and presentation in terms of the general concepts, is helping Understandability. But too many details can hamper the users view so Invisibility is equally important. Mechanisms for Construction (putting things together) which hide details, and the reverse, De-construction, is a way for the user to control Visibility. In Palcom the main mechanism for the user to Control and Automate is the Assembly construct. In an Assembly a user can express both what parts make up a configuration, and how the parts interact. An Assembly is also a mechanism that support
hierarchical Construction/De-construction on the configuration level, and bridging between incompatible services, i.e. Heterogeneity on the interaction level. The configuration expressed in Assemblies can be seen as rules which needs to be fulfilled in order for the Assembly to be (fully) operational. Enhancing this mechanism is the avenue we want to explore for offering the user to express control over configuration using automation. In an increasingly complex situation, with the emerging ”Internet of Things”, we see an increasing need for such mechanisms. 3. PREVIOUS WORK We will briefly compare Palcom to two systems that address one aspect each, also addressed by Palcom. The Palcom architecture can be compared with Obje [4] (also known as Speakeasy [5]) which focus on the problem of incompatible application protocols. It use mobile Java code as a way to bridge such differences. We share the approach of not resorting to using standards on the domain level for interoperability. We have, however, chosen to use a meta-level protocol for the communication and scripting in Assemblies for the adaption. We see several advantages with our approach. In earlier experiments with mobile Java code we learned that over low-bandwidth networks, such as BT, the transfer of code, and thus time to establish a connection, became painfully long. It also put a demand on all devices to include a JVM, which might exclude many small devices. Furthermore, the introduction of the mobile code introduces a dependency between services which we avoid by placing the adaption in an Assembly between the incompatible services. Choosing a script language for this also enables non-programmers to perform, at least, simple, integration tasks. Regarding user control, the Personis system has similar aims as we are considering. In [6] they describe a mechanism for user control of web services instrumented with an accessible user model. The model has an API (access/ask/tell) through which it can be controlled. In a simple application they illustrate how a music service can be parameterized to deliver music matching the taste of the user. In Palcom a similar effect, as in this example, could be achieved through a Service attached to the model having for example a similar API with access/ask/tell messages. A user could then exercise control through the direct access mechanism in Palcom. A difference is that our focus is more on mobile devices and problems of configuration - which devices are available, working, actually used, can be used as replacement, etc. A typical scenario would be in intensive care where equipment often is added incrementally. Additional functionality could be enabled automatically as combinations of devices are available, but needs to be under user control. The question in such a setting is thus how the end user can automate the behavior while still being in control and understanding how and why the behavior is influenced. 4.DESIGN PRINCIPLES IN PALCOM The design of the Palcom platform is based on the idea of separating between: • Computation • Configuration • Coordination Computation is what is performed by Services. Example of Palcom Services are computations such as calculating a health index from medical measurements, finding the position of an object in a picture, calculating the control signal to control a
mobile robot, etc. Services can also be sensors, providing GPS positions, Heart rate, temperatures, pictures, video streams etc. Configuration determines which services are involved in a scenario. In Palcom configurations are specified in Assemblies. An Assembly can specify several alternative Services and gives an order of priority for their use. The Palcom framework tries to establish connections to these Services as they are available. An Assembly can adjust its behavior according to the situation and have a status that can be Green (Fully operational), Yellow (Partially operational), or Red (Not operational). Coordination is how the configured Services interact. This is specified as a script of event-driven actions, the second part of an Assembly. This can be seen as the logic of the assembly, and can in its simplest from be used to translate between incompatible services. With the two kinds of components, Services - that act as providers, and Assemblies - that act as customers, one can create configurations that are different from configurations based on client-server or peer-peer. Rather than having one service connect to another, an Assemblies can be seen as "patch-cable" between services. Since an Assembly can have more than two "ends" it can specify many connections, and thus collects the configuration in one place, rather than spreading this information out over, and mixing it with, the computational services. An Assembly can also, in its turn, provide new services. With these mechanisms one create configurations that are different, and more explicit than with other mechanisms such as client/server and p2p. We have found that they lead to less dependencies between the components, and thus make them simpler to change and reconfigure. 5.THE PALCOM ARCHITECTURE The realization of Palcom middleware offered some interesting design choices [7]. Taking the view that pervasive systems are more about communicating mobile devices than about internet connected computers, we are using the notion of Device for addressing equipment. For a user, the identity of the actual piece of equipment is almost always essential. "I want to take a photo with my camera", "monitor the pulse from that sensor (attached to Mr X)", or "print on the printer on the third floor", as opposed to the view that any service would do. Using a unique id for the device for addressing is in contrast to using interface addresses (such as IP-numbers) since there might be several of these, maybe using different technologies. This allows us to identify a Device irrespectively of the way it have been contacted, and change connections dynamically as networks come and go, which is typical in a mobile network. Introducing DeviceID is thus a way to support Stability, and Coherence across heterogenous networks. Palcom uses a discovery protocol to find Palcom devices on a network. As a result each node builds up a table of the devices it has found on each network it is connected to, translating between DeviceID and the address of the device on the particular network. Palcom is thus self-configuring and detect devices as they become available and become unavailable. The basic discovery mechanism is limited to local networks (e. g. the part of an IP network available with broadcast, a BlueTooth network etc.). Such local networks can be bridged by devices with more than one interface which can act as routers between the networks. There is also a Palcom tunnel mechanism that can connect local Palcom networks and forward discovery and communication between them in a transparent way. The communication in a tunnel can be encrypted when desired. The communication between devices can use the different networks as they are available from message to message. Established connections are explicit and can be
discovered and listed. Discovery support Visibility of Devices, Services and Connections across networks. Each Palcom device can provide a set of Services that Assemblies possibly on other devices can connect to. A Service comes with a description of its interface, what messages it can send or receive, parameters etc. It is up to the user of a service to adjust to its interface which is done in the coordination part of Assemblies. There is thus no standard for services, but new services can be invented as needed and Assemblies can be adapted to Change and bridging between heterogenous Services and thus application protocols. A Service can be used in two ways. The description of a Service interface can be used to render a user interface which allows a human to directly interact with a service using a browser. This is useful for finding out how a service works, make sure that a service still works, and sometimes services are just what you need. Direct interaction with Services thus support Visibility and Understandability. A Service can also be used as a programmatic interface. Connections to services are collected in the Assembly construct. An assembly can connect to several services and each connection from the assembly is adjusted to the service in question. The actions of an assembly are defined by a script in the assembly. It has the form of actions specified as reactions to incoming messages. Reactions can be of the form of sending new messages to connected services or storing/loading local variables. Assemblies can also provide new services, which other assemblies can connect to, thus providing a hierarchical structuring mechanism. Coordination scripts in Assemblies is the mechanism for providing user control at the service interaction level. There is also the possibility to introduce new Services for control and automation on the programming level for the expert user. Services are written in Java, while Assemblies are created with a Palcom browser and interactive editor in a domain specific language. Together these tools provide a fairly comprehensive development environment. There is a Palcom runtime environment where Services and Assemblies can be installed and executed. Palcom runs on popular computers (Mac, Linux, Windows) and equipment such as Android phones and (some) AXIS cameras. It has also been integrated with dlna (making TV-sets etc available as Palcom devices), 1-wire (making a variety of small and cheap sensors available as Palcom services), and NEXA computer controlled power sockets. Together these interfaces make home automation available for experimenting in Palcom. 6.DISCUSSION Summarizing from the presentation above Palcom offers some mechanisms for control and understanding. • Discovery of Services, Assemblies and Connections provide an overview to the user. • Direct interaction with a Service provides for direct control. With the Assembly mechanism the user can control: • what Services on what Devices to use, • how they should be coordinated. The experienced programmer can provide new functionality as • Services implemented in Java, or • interface to existing systems making them appear as Palcom Services. As the number of available devices (and services) grow, we expect the configuration part to become increasingly cumbersome to manage. The current configuration binding mechanism is already rule-based although not yet very developed. The mechanism allows the assembly designer to specify which Palcom Devices (and Services) to connect to. The Palcom execution
environment will then try to establish, and re-establish, these connections as the devices and services become available, and are discovered. There is a hint of dynamic behavior and adaption to a changing situation through the possibility to specify alternative Services. The Palcom environment will make sure the one with highest priority of those available is used and change dynamically as they come and go. A simple example of use would be to specify alternative positioning services: GPS, GPS in mobile, cell triangulation, motivated by decreasing precision or speed. The current design only allows for bindings in Assemblies that goes to previously known devices. More dynamic rules for binding to Services could be based on several possible principles, for example on different distances: • geographic location (e.g. closest matching service) • matching type (e.g the service with most matching messages) • social network (e.g. the service most of my friends ”like”) • the device I look at. Although in particular situations useful, a system built on such principles could be found to behave unexpectedly for some users. So relevant questions include; How can we make it Visible for the user what bindings are actually in place? Is it Understandable why the bindings are selected? What is a reasonable balance between Change and Stability, and how can the user take control when desired? 7.ACKNOWLEDGMENTS We are building on the work and concepts developed in the EU project Palcom, and are grateful to the many people who were involved. We are also thankful for the funds provided by VINNOVA and SSF in support of this research. Without concrete scenarios, and equipment it is hard to do realistic experimental research. We are therefor thankful for the support from Sony Ericsson, AXIS and the University Hospital at Lund. 8.REFERENCES [1] Mark Weiser. The Computer for the 21st Century. Scientific American, 265(3):66–75, February 1991. [2] palcom http://www.ist-palcom.org/ [3] PalCom Project. Open Architecture, Deliverable 54. December 2007. See [2] [4] Obje Interoperability Framework, 2003. http:// www.parc.com/ research/projects/obje/Obje_Whitepaper.pdf. [5] W. Keith Edwards, Mark W. Newman, Jana Sedivy, and Trevor Smith. Challenge: Recombinant Computing and the Speakeasy App- roach. In Proceedings of ACM MOBICOM’02, September 2002. [6] Judy Kay, Bob Kummerfeld, Piers Lauder: Personis: A Server for User Models, In AH '02 Proceedings of the Second International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems, Springer-Verlag London, UK, 2002. [7] David Svensson Fors, Boris Magnusson, Sven Gestegård Robertz, Görel Hedin, Emma Nilsson-Nyman: Ad-hoc Composition of Pervasive Services in the PalCom Architecture. In Proceedings of International Conference on Pervasive Service, ICPS09, ACM, London July 2009.
