Software Organization for Dynamic and Adaptable Wearable Systems Stephen Fickas Computer Science Dept. University of Oregon Eugene, OR 97403 USA
[email protected]
Gerd Kortuem Computer Science Dept. University of Oregon Eugene, OR 97403 USA
[email protected]
Abstract There is a growing interest in a class of systems having dynamic and adaptable properties. In this paper we discuss our work on one subclass of such systems, that of wearable computers. In particular, our interest is in the software organization necessary to build wearable computing systems. We will examine some of the key properties of such a software organization such as the ability to rapidly and dynamically reconfigure software to meet both physical changes and information changes of the wearable system. This has lead us to study a middleware layer for a wearable system that supports dynamic reconfiguration. The middleware approach is studied in the context of the NETMAN - a network maintenance assistant. Current results from the system evaluations and the final system requirements and open issues are presented.
1. Introduction Our group is interested in dynamic, adaptable systems. In this paper we discuss our work on one subclass of such systems, that of wearable computers. For the past two years, faculty and students from the University of Oregon and CMU have worked jointly on the hardware and software to support a wearable computing environment. For the most part, the Oregon group has focused on the software environment necessary to build wearable computing systems. The remainder of the paper will describe what we have found to be a key property of the software environment: the ability to rapidly and dynamically reconfigure software to meet both physical changes and information changes of the wearable system.
Zary Segall Computer Science Dept. University of Oregon Eugene, OR 97403 USA
[email protected]
This has lead us to study a middleware layer for a wearable system that supports dynamic reconfiguration.
2. The Oregon Wearable Computer The University of Oregon wearable information system is a body-worn computer designed for tasks that require hands-free operation. The computer is housed in a specially designed vest that accommodates the various batteries and input devices required. The central processing unit is fitted into a pouch in the small of the back, and cables are run from the CPU out to the front pockets in the vest. These cables feed the batteries and input devices positioned in the front of the vest. The weight of the batteries and accessories counters the weight of the CPU pouch on the back, providing a comfortable fit (Figure 1 and 2).
2.1. Hardware Design The design philosophy followed in building the vest was centered around COTS, or commercial off the shelf hardware. The COTS approach allowed us to purchase the parts of our wearable computer through traditional consumer outlets. The computer itself is a Texas Instruments Pentium 75, Asentia motherboard. The video capture hardware is the inexpensive Snappy from Play Incorporated. A chorded keyboard (Twiddler) was purchased from Handykey, and the mouse is an Alps glide point. The monocular heads-up display is constructed from a pair of Virtual-IO glasses with a resolution of 180000 pixels. We choose to modify the V-IO glasses by removing one of the eye pieces. This was done to provide an unobstructed and a more natural view for enhanced reality. It was shown that a monocular view could more This research was supported in part by the National Science Foundation (NFS) under grant MIP 9403573. The content of this paper does not necessarily reflect the position or policy of the NSF or University of Oregon.
equipment such as routers; performing regularly scheduled maintenance work; troubleshooting of network faults; repair and replacement of faulty equipment. Figure 1 and 2 show a network technician performing a maintenance task on a network closet. Using the heads-up display he can look up information in remote databases or use software tools for identifying faults in network equipment. Figure 1. easily provide content that was unobtrusive, while at the same time allowing the user to switch focus between the data on the display and the work at hand, without eye strain, or movement of the HMD.
2.2. User Interface The primary form of user input is speaker dependent voice controls. The user trains the computer to interpret voice commands by completing a voice training exercise, that familiarizes the user with the various commands available. Alternative forms of user input are provided by the Twiddler keyboard, a pointing device, and a barcode scanner. The head mounted display provides both auditory and visual feedback.
2.3. Networking The wearable computer is equipped with a wireless modem that enables access to a campus-wide wireless network. This network, which is provided by Metricom, offers a reliable connection to local area networks and the Internet with speeds of up to 28800 baud. An alternative form of network connectivity is provided by an infrared transceiver which allows the wearable computer to exchange messages with other IR equipped devices like printer and desktop computers. The IR system is also used to determine the wearable computer’s location within a building (see below).
A network technician using our wearable device may be required to roam from an office, to a patch panel, to a cable tray, and eventually to an individual machine. Each change of location brings with it the need for new information, new peripherals/probes and new sets of software tools. The network maintenance application embodies all of the properties of a wearable application that stresses the concept of dynamic and adaptable systems. We call this wearable application NETMAN.
3.2. Environment-Directed Computing Our goal is to design a flexible wearable computer system that can automatically adapt to changes of the user’s task, the availability of computational resources (such as network bandwidth), and the situational context. Together these factors represent a dynamic working environment for the wearable computer. By monitoring changes in the environment the computer can adapt its operation according to predefined or user-defined guidelines. We call this concept environment-directed computing. To determine the user’s task and situational context we have designed an infrared beacon system that allows the wearable computer to perceive its physical environment by means of infrared signals sent out by physical objects. To this end, we have augmented part of our lab space with a net of infrared transmitters which at regular intervals send out unique identification tags that can be received by the infrared receiver of the wearable device (see also the
3. NETMAN 3.1. Application Domain Our primary application domain for wearable computing is that of network maintenance. Our goal is to design and develop a wearable system that helps technicians in their daily task of troubleshooting and repairing faults in computer network equipment. For collecting requirements we are working closely with the University of Oregon Computing Center which is responsible for maintaining the computer and network installations throughout campus. Typical tasks of technicians include: installation of new network
Figure 2.
Database Server
IR Beacon
Beacon ID Beacon ID [IR network]
relevant information [radio network] Wearable Computer
Architecture 1: Information Pull
IR Beacon
(ID, location) [wired network]
Computer ID
Database Server
relevant information
[IR network]
[radio network] Wearable Computer
Architecture 2: Information Push
IR Beacon
[IR network]
relevant information
Wearable Computer
Architecture 3: Information Push
Figure 3. System Architectures for Environment-Directed Computing Active Badge System [15] and Poor’s work at MIT [14]). The beacon system gives the wearable computer the ability to 1.
identify individual objects in its immediate surrounding by identifying their unique signals;
2.
determine its own location in relation to known objects and - by means of a geographical database its absolute location;
3.
exchange arbitrary information with individual IR transmitters; information can be just data, but also executable or interpretable code. This makes it possible to automatically load code fragments or entire applications (applets) from the environment onto the wearable computer as side effect of the user’s physical movements. The IR beacon system can be used in a number of
ways: first, the computer can automatically retrieve and display information relevant to the user’s current location or task (context-dependent computing). For example, the computer can automatically compile information from remote data sources pertaining to the equipment the user is currently working on instead of requiring the user to actively query for it. Second, specialized software tools for troubleshooting network equipment can be automatically loaded onto the wearable computer whenever the user approaches an IR equipped network device. The decision when to load (and unload) software components to (and from) the wearable computer depends on and requires knowledge about the current state of resources like network bandwidth, remaining battery lifetime, and disk space. Figure 3 shows three alternative system architectures for our IR beacon system. In the first architecture, the wearable computer actively queries a server for relevant information after receiving a beacon from an IR transmitter (information pull). In architecture 2 and 3 relevant information (data and/or software) is sent to the wearable computer (information push). While architecture 2 uses a server to store information in a central place, in the third architecture information is stored in a distributed fashion in the local memories of IR transceivers. This has the advantage that IR transmitters can be completely selfcontained devices that do not require a network connection. Our current implementation of the IR beacon system follows the second architecture, but we are actively working on self-contained IR transmitters.
3.3. System Properties In summary, the wearable systems that we study have the following properties: 1.
We are working with wearable devices that have limited capacity in one or more of the following areas: main memory, secondary memory, processor speed, power.
2.
We are working with wireless communication that has limited capacity in one or more of the following areas: availability, bandwidth, reliability. Further, we cannot expect symmetric communication in any of these areas, e.g., we may have a high bandwidth, reliable connection as a downlink and a low bandwidth, unreliable (or non-existent) uplink. Of course, this symmetry can fluctuate over the life of a task.
3.
Users of a wearable device will move through different information contexts, e.g., to complete task
A, a user must first complete sub-task B. Each context may require a different information/software tool set. 4.
5.
6.
Users of a wearable device will move through different physical contexts. This can be tied to switches in information context (e.g., moving from a network closet to an individual machine) as well as problems in communication hand-off and loss. The hardware of the wearable device might change as new tasks or information contexts are encountered, e.g., new probes may be plugged into the wearable as a network failure is refined from the LAN level to the wire level. Similarly, in some occasions the user might add a camera and microphone to the wearable computer for remote collaboration with experts. Because of the additional weight of these components they might be left in the office when not used. The wearable environment may be active: other physical objects in the world may have the ability to send or receive information from the wearable device. These "active devices" may or may not be networked. In the simplest case, a device may simply make its ID known. In more complex cases, a wearable may carry on a conversation with an object.
Given these properties, we envision wearable computers to have dynamically changing software configurations that are updated continuously according to the user’s current task and situational context. We have begun to look at the software infrastructure that is necessary to operate such a wearable system. What we describe in this paper are our first attempts to build a wearable middleware software layer that acts as this infrastructure, and the open research questions that this has raised.
4. Software Infrastructure Requirement 1: Given limited processing resources on a wearable system, decisions must be made on outsourcing of processing based on a combination of available local resources, available remote resources, and capacity and sustainability of data connections. Example: The NETMAN is called upon to analyze a collection of packet data for information on why bootp is failing. The analysis can be done locally and immediately with a substantial cost in battery power and a shutdown of other ongoing local tasks. The analysis can be out-sourced to an unloaded high-performance computer (HPC) but at the cost of shipping local data (and/or code) over a currently saturated connection. Requirement 2: Given the lack of constant and high-
bandwidth data connection to wired LANs, data on a wearable system can become out of date. Decisions must be made between the use of less than up to date local information and the use of more accurate remote information. Example: NETMAN requires information on the current topology of a specific LAN it is troubleshooting. There is local topology information that is left over (cached) from a previous application. This information is possibly out of date. Up to date information can be gained by querying a remote server. However, a wireless connection will have to be established with the server. A decision is needed. Implications: The implication of both requirements 1 and 2 is that we field a decision support system that can tie the probabilities of a shifting domain (e.g., the probability that the server information is more up to date, the probability that the information can be downloaded in a timely fashion) to the cost and eventually the value we place on certain tasks being completed, possibly under deadline (e.g., what is the most up to date information worth to us, what is the cost of establishing and sustaining a data connection). Requirement 3: We will need to marshal resources. We fully expect the individual components of a larger tool set needed by a wearable to be distributed among the wearable itself and one or more remote devices. The wearable may or may not know the exact location of each tool, i.e., search is a possibility. Example: NETMAN is being used to troubleshoot a non-booting workstation. The current task is to determine connectivity between the workstation and the bootp server. To do so requires a suite of tools (e.g., ping service, traceroute, packet analyzer, collaboration tools which allow the NETMAN user to “talk” with someone on the server side). Some of these tools may reside on the wearable, some on remote machines. Implications: We require a means of pulling together the tools we need for the task at hand. Requirement 4: We need to manage the resources we keep on the wearable optimally. Given limited resources of power, space, processing ability, local resource management is a necessity. Example: A NETMAN troubleshooting session may stretch over hours or even days. It will typically involve moving through a set of sub-tasks as well as a set of physical locations. While each new sub-task may bring the need for a new tool set configuration, it is not uncommon for configurations to share some set of individual tools.
Wearable Computer Application Manager
The Configuration Manager keeps track of hardware and software components installed on the wearable device such as memory configuration, sensory devices, system software components, and optional hardware devices like a camera. In addition, it maintains dependency information in order to track which software requires which other software or hardware. This information is used for resource qualification as described below.
Application Application Application
Configuration
Decision Maker
Manager
Manager Cache
The actual middlelayer consists of four submodules.
Resource
Manager
Network Layer
Figure 4. Wearable Computer Software Architecture Implications: As a wearable user moves among subtasks and physical settings, she will typically require new information and new application configurations. Given that it is impossible to pre-load every possible software configuration on the wearable device, we are left with devising mechanisms that make the download of new software, either through push or pull means, more efficient.
4.1. System Architecture We have devised and partly implemented a software infrastructure for a wearable adaptable system. The entire software organization of the wearable device consists of four layers as shown in Figure 4. The highest layer is formed by the Application Manager, a graphical user-interface that allows the user to control the execution of individual applications. In addition, it provides feedback about the status of the wearable device (battery life, network connection etc.) and ongoing operations. The second layer is represented by the software applications currently present on the wearable device. Applications can be loaded or unloaded dynamically. We have devised a mechanism which allows us to load entire application configurations over a network and install them onto the wearable computer.
The Resource Manager monitors and makes available status information about important resources of the wearable device. Resources include disk space, available network bandwidth, accessibility of vital remote resources like servers, remaining battery life, etc. The Decision Maker uses probabilistic methods to reason about the operation of vital system functions. For example, the decision maker is used to determine whether to store data and/or software components locally or remotely. Another typical task of the decision maker is to decide whether a task should be run locally or remotely on a dedicated compute server. The decisions are made based on a built-in formal model and the current state of monitored system variables such as installed components and resource availabilities. The Cache is a persistent data storage that can be used by applications to store data locally on the wearable device. If the amount of cached data exceeds the available resources, the Decision Maker can decide to remove individual data items. All submodules of the middlelayer provide an application programming interface which allows wearable applications to use services provided by the middlelayer. For example, applications can use the Decision Maker to decide whether to perform operations locally or to spawn a subtask on another machine. The network layer finally provides a network interface that isolates applications and middlelayer from specific network characteristics. In particular, it hides the fact whether communication occurs over wireless radio network or over a infrared network.
4.2. Resource Qualification The information maintained by the resource manager and configuration manager is used for resource qualification, a process by which we ensure that applications and other software components to be loaded onto the wearable device do not exceed the available resources. Resource qualification is performed whenever software
RAM
“Navigator”
Open issues: Using Strategist in the NETMAN environment has raised a set of research issues: 1.
Tcl/Tk Interpreter
network driver preference file “init.dat”
sound DLL
modem card
sound card
Figure 5. Partial Resource Dependency Graph is loaded onto the wearable device, whether it is pulled from a server by the wearable device itself or is pushed onto the wearable device. Configuration and resource information is represented as resource dependency graphs. A resource dependency graph is a labeled graph where nodes denote resources and links dependencies between resources. Figure 5 shows an excerpt of a dependency graph as used by the configuration manager. It expresses the fact that the application “Navigator'” directly or indirectly depends on seven other resources, some of them software and some of them hardware resources. Labels (which are not shown in Figure 5) are used to qualify the dependency. For example we can express the fact that an application requires 8MB of memory and 2MB of free disk space. Using resource qualification we can guarantee that software components to be loaded onto the wearable device can actually be executed in the local environment and that installed software is compatible with the hardware and software platform. For example, loading software that allows two users to communicate using voice (such as an Internet phone application) does not make sense if the wearable computer is not equipped with a microphone or speaker.
How is a decision system kept up to date?
A Strategist model is based on event probabilities. In the wearable environment, these probabilities are often shifting over time. We are beginning to explore the use of agents working on behalf of Strategist to maintain model probabilities. In particular, we have begun to study the means Strategist can gather information on-demand. Our current approach uses agents to retrieve up to date information when it is needed. Returning to our example of deciding between using out of date but local information versus downloading potentially more up to date information off of a remote server, one variable influencing the decision will be the time to download. This in turn rests on the probability of sustaining a specific bandwidth for a given period of time. We have written an agent who can probe a communication channel for bandwidth statistics and map this into a probability distribution for use by the Strategist model. Of course, given that there is no free lunch on a wearable – launching and managing agents costs resources – there is the question of how much effort to expend for any particular model. We have found that this has close ties to what the Uncertainty in AI (UAI) community has called the "value of information" issue: what variables in a model are worth knowing accurately? It is these variables that we may wish to provide attached agents. 2.
When can decision support be implemented by compiled policies?
5. Experiments
Given that running Strategist on the wearable costs resources, when can we use Strategist to analyze runtime scenarios at compile time, i.e., before the wearable is put into action in the task domain? This will leave us with a runtime decision matrix that often takes a fraction of the resources of the full Strategist runtime system.
5.1. Runtime Decision Support
3.
We have begun work on hosting a runtime decision support system (DSS) in our middleware layer. The DSS tool that we are using is Strategist from Prevision [1]. Strategist is based on influence diagrams, which in turn are based on Bayes Nets. Strategist is well suited to decision problems that involve probabilistic information tied into utility or value tables.
Related to both issues 1 and 2 above, it costs resources to run Strategist on the wearable. Can we make resource efficient decisions at runtime on whether to invoke a Strategist decision process or go with a quick-and-dirty compiled solution (e.g., “always get the most up to date information”)? Of course, this is a decision process in itself.
The decision maker provides an API that allows applications to make use of its decision making capabilities. For example, an application can use Strategist to determine whether to run an analysis onboard or pass it off to a powerful server.
5.2. Resource Qualification
Going meta may be necessary.
Our first efforts have focused on pulling necessary pieces together on the wearable computer. We devised a recursive descent algorithm that uses the resource dependency graph to locate and download individual
pieces of a tool set that is needed for a specific task at hand. This has proven sufficient to allow us to run an interesting set of NETMAN examples. Open issues: Having built a suitable infrastructure for dynamic configuration management we are now planning to move towards a more open distributed computing paradigm based upon an integration of CORBA and JAVA. This will allow us to turn our attention to a new set of questions: 1.
Ties to Application specific scheduling.
Can we tie the problem of marshaling of wearable resources into the broader question of application level resource management on the Internet? For instance, Wolski [2] is designing an “Internet Weather Service” at UCSD as part of a meta-computing environment. His service uses past, current and predicted communication bottlenecks and packet storms (the weather) to bring resources together for an HPC application. We have begun to look at tying our local DSS tool into a larger model of the wearable environment supporting application specific scheduling. 2. Quality of Service (QoS). The notion of levels of quality brings a much needed flexibility in the dynamic environments we work in. Instead of an all or nothing view of the world, we can reason about the quality (in terms of information accuracy, processing resources, connection) we are willing to live with given the cost to achieve various levels. For example, we have found ourselves reasoning about the type of collaboration tools we will marshal for certain NETMAN tasks. In some cases the ideal is full audio and video between the NETMAN user and an expert at a helpdesk. However, this makes sense only if we can maintain a level of connection quality. Once this slips below threshold, we need to move to a lower quality tool (e.g., audio or even text chat) to match the connectivity resources we have. Currently we carry out this dynamic adaptation of tools manually. We would eventually like to make it part of the middleware layer, itself.
5.3. Cache Management The idea to reconfigure and adapt a wearable computer by dynamically loading and unloading software components requires strategies for making efficient use of limited resources such as bandwidth, and battery lifetime. We have looked at caching as a means for reducing the amount of information that has to be transferred between the wearable computer and its environment. In particular we are interested in caching strategies that make decisions based upon the actual costs of loading or unloading
components from the cache. We have developed and evaluated a cache replacement strategy that uses two criteria to determine which components (data items and/or software components) should be cached locally and when they should be removed. Cost: By cost we mean the cost of reloading a component once it has been removed from the cache. We define cost in two alternative ways: 1. In the first approach, cost is defined as the time it takes to reload a component once it has been evicted from the cache. The reload-time is determined by the size of the component and the current available network bandwidth to the server the component is stored on. The larger the size of a component and the lower the available bandwidth the higher the cost. Under this scheme, two components with the same size can have different reloadcosts if they are stored on servers with different network characteristics. The cost measure based on reloading-times is not static, but varies over time depending on the current state of the network. It is thus necessary to reevaluate the cost of each component periodically, for example by probing the available network bandwidth to the respective servers. 2. In the second approach, we define the cost of a component as the amount of energy that is required to reload it. Energy usage is a critical measure that directly determines the lifetime of batteries. Many application domains require uninterrupted usage of the wearable computers over several hours which with current technology can only be achieved by carrying several sets of batteries. Since batteries are bulky and heavy they significantly influence the form factor and possible usage of today’s wearable computers. The energy required for loading a component is directly related to the amount of data that needs to be transferred, but also depends on how often a network connection is torn down and needs to be reestablished. Establishing a network connection over a dial-up network is costly. Importance: The second criteria we use in managing the cache is importance. Importance is defined as how critical a component is for the functioning of the various hardware and software components of a wearable computer. For example, in order to use a camera or any other external device, certain system software components (device drivers etc.) have to be installed on the wearable computer. Removing such components can render the wearable computer non-functional, thus they are more important than, let’s say, a rarely used diagnostic tool.
More formally, we define importance of a component as the number of other components that depend on it. This information can be extracted from the resource dependency graph maintained by the configuration manager; it is equal to the number of incoming dependency links in the transitive closure of the dependency graph. The higher the number of incoming links, the higher the importance of a component. In general, it is preferable to remove the least important components first. The concept of importance is not a mere technical measure of existing dependencies between hardware or software components. In more than trivial cases the importance of a component can only be evaluated in the context of the user’s tasks and goals. More details on this topic can be found in [12]. Open Issues: We have come to the conclusion that cache management has to be viewed as one more piece of a dynamically changing and adaptable middleware layer. In a dynamic environment it is necessary to reevaluate the current strategy and adjust it if necessary, instead of using a static policy, fixed at predeployment time. An important question for the future is how the various criteria used for defining a cache replacement strategy (reload time, energy usage, importance) can be combined effectively into an overall decision model.
References [1] Strategist by Prevision, http://www.prevision.com/strategist.html [2] F. Berman, R. Wolski, S. Figueira, J. Schopf, and G. Shao, "Application-Level Scheduling on Distributed Heterogeneous Networks," Proceedings of Supercomputing ’96, November, 1996. [3] F. Bennet, Richardson T. and A. Harter. “Teleporting Mobile Application”, Proceedings of the Workshop on Mobile Computing Systems and Applications, December 1994. [4] T. Fallmyr. “Adaptable Mobile Systems”, IEEE Workshop in Future Trends in Distributed Computing, August 1995. [5] D. Goldberg and M. Tso. “How to Program Networked Portable Computers”, Proceedings of the 4th Workshop on Workstation Operating Systems (WWOS-IV), October 1993. [6] M.F. Kaashoeck, T. Pinckney, and J. A. Tauber. “Dynamic Documents: Mobile Wireless Access to the WWW”, Proceedings of the Workshop on Mobile Computing Systems and Applications, December 1994. 7] J.J. Kistler and M. Satyanarayanan. “Disconnected Operation in the Coda File System”, Proceedings of the Thirteenth ACM Symposium on Operating Systems Principles, Pages 213-225, 1991. [8] Sun Microsystems, “Java White Papers”, http://www.sunsoft.com/doc.
available at
Given this view, how can we adapt our cache strategy to meet changing resource availability? For instance, we may have predictable and sustained “blasts” of bandwidth for short periods of time (e.g., when the NETMAN is able to plug in to an Ethernet wall socket). Under these conditions, we may be best off moving to a “standard” cache strategy. Once this connection is lost, other strategies will likely be more appropriate. In essence, strategies are needed for managing a cache as a dynamic, adaptable service.
[9] B.N. Schilit, N.M. Theimer and B.B. Welch, “Customizing Mobile Applications”, in Proceedings USENIX Symposium on Mobile & Location-Independent Computing, Pages 129-138, August 1993.
6. Conclusion
[12] Gerd Kortuem, Steve Fickas, Zary Segall, “On-Demand Delivery of Software in Mobile Environments”, Nomadic Computing Workshop, 11th International Parallel Processing Symposium, April 1-5, 1997, Geneva, Switzerland. Available at http//www.cs.uoregon.edu/wearables/Papers/nomadic.ps.
We have designed, implemented and partially evaluated a software infrastructure for wearable computer systems. We are emphasizing the dynamic adaptability requirement for this class of systems. Our results are pointing out the need for a middleware layer capable of presenting a number of run time mechanisms and policies allowing for dynamic application reconfiguration and outsourcing. Our initial experience and measurements with the NETMAN wearable system shows our approach to be sound. Given the novelty of this field we see value in pointing out our view on the requirements and the open research questions related to the optimal structure of the software organization for wearable information systems.
[10] T. Watson, “Application Design for Wireless Computing”, in Proceedings of the Workshop on Mobile Computing Systems and Applications, December 1994. [11] Steve Fickas, Gerd Kortuem, Zary Segall. Computing Web Site, University of http//www.cs.uoregon.edu/research/wearables.
Wearable Oregon,
[13] Steve Fickas, Gerd Kortuem, Zary Segall, “NETMAN: Collaborative Network Maintenance with Wearable Computers”, submitted to GROUP97, available online at http//www.cs.uoregon.edu/wearables/Papers/group97.ps. [14] Poor, R. (1996), “IRX 2.0”, available online at http://ttt.www.media.edu/pia/Research/iRX2/index.html. [15] Roy Want, Andy Hopper, Veronica Falcao, Jonathon Gibbons, “The Active Badge Location System”, ACM Transactions on Information Systems, Vol. 10, No. 1, January 1992.
