NEWS AT SEI
This library item is related to the following area(s) of work:Software Architecture
This article was originally published in News at SEI on: March 1, 2002
The architectural paradigms that have been used to build non-mobile systems do not fit the needs of mobile systems particularly well. Mobile systems require effective methods to manage and control their resources, particularly in the face of changing environmental conditions and user needs. SEI staff members are examining the application of adaptive architectures to maximize the user-defined utility of mobile devices within the limits of their available resources.
The computational environment that the average person is exposed to is changing rapidly these days. In particular, we are seeing the widespread commercial presence of mobile systems: cell phones and personal digital assistants that combine voice and data communication and other applications on a single device. And this trend towards mobility appears to be steadily increasing. But the architectural paradigms that we have been using to build non-mobile systems in the past do not fit the needs of mobile systems particularly well. For one thing, mobile systems are, and always will be, more constrained with regard to resources than their stationary counterparts. As a result, the architecture of mobile systems has to be carefully balanced between the physical size of the system and its computation, communication, and energy capacity. And resources need to be allocated differently on mobile systems. Currently, resource-allocation decisions on mobile systems are almost always fixed at the time of system creation. This is partly due to the very limited resources available on most mobile systems and partly because typical mobile systems are used for a small set of operations that are well known in advance (e.g., phone calls, Web browsing, short message service, etc.).
This situation is changing, however, and modern mobile systems are becoming more powerful in terms of the computation and communication resources that they can call on. At the same time, as they become ubiquitous, the demands being placed on them are increasing. For this reason, such systems must have effective methods to manage and control their resources, particularly in the face of changing environmental conditions and user needs. At the SEI, we are examining the application of adaptive architectures to maximize the user-defined utility of mobile devices within the limits of their available resources. The novelty of this approach is that we are making resource-allocation decisions based upon user-defined notions of utility (essentially a subjective notion of goodness), as compared with traditional approaches to resource scheduling, which focused on purely internal or technical notions of goodness, such as throughput, latency, or resource utilization.
Mobile systems must be adaptable for a number of reasons: they have limited resources; user needs are constantly changing as the user’s environment changes; and resource availability constantly changes as the user moves around, as environmental conditions change, and as time passes. For example, as users move around, the signal strength that they are receiving will change. And as time passes, the amount of available energy (battery) normally decreases.
We believe that the best way to make adaptive mobile systems is to use a user-defined utility-based approach to resource allocation. By choosing “utility” as the central concept on which adaptation rests (rather than, say, more traditional notions such as maximization of CPU utilization or throughput), we can create systems that adapt in ways that more closely mirror a user’s needs, which may be changing dynamically. For example, at one moment a user might want to surf for some files on the Internet, but if an important call comes in from a client, he or she might want to allocate more resources to that call and less (or even none) to downloading a file from the Web.
Most common scheduling and resource-allocation approaches rely on relative priorities of computational elements, such as threads, processes, and programs. However, on a personal mobile device this approach must be extended to a utility-based resource-allocation mechanism, where utility is purely user defined. In this view of the world, application services that have a high utility to the user get a preferential allocation of resources.
A mobile personal-communication device serves multiple purposes. That implies change in user preferences. User mobility implies inevitable changes in environment, affecting connectivity to communication and sources of energy. Mobility also leads to change in the dominant use of the device. Utility-based resource allocation must be dynamically adaptable to these changes. A direct consequence of this is that mobile applications are expected to be able to run at different fidelity levels providing a different level of utility to the user and having different resource requirements. For example, if a user is browsing the Web, different fidelity levels might take the form of text only, text with minimal graphics, and text with full graphics. Voice communications might have different levels of fidelity corresponding to different CODECs that run at different data rates. Video communications might have different resolutions, color depths, and numbers of frames per minute. And so forth. In each case, the resource requirements for these applications are different, and the resulting utility that they provide to the user is different. In addition, a user’s subjective view of the utility of these different levels of fidelity might change depending on the situation. For example, the user might demand high voice quality for an important business call with a client, but might be perfectly content with a low voice quality when checking sports scores or receiving unsolicited calls. Even within a single run of a single application, the fidelity demanded by a user might change dynamically.
Clearly the design space in creating such systems is enormous. There may be different configurations of the hardware and software components, and different quality attributes that the user may want to optimize (e.g., communication speed, battery life, and performance). This enormous design space poses a problem for designers—how can they go about comparing architectural alternatives for such systems without having to go to the expense and risk of building the systems?
To be able to conduct research in determining appropriate architectural alternatives for dealing with all of these complexities, we need to create a simulation test bed. The research questions that we propose to answer from this simulation test bed can be organized into two broad categories:
Implementation: Is it possible to build a system that incorporates user preferences and dynamically optimizes the assignment of resources to maximize user satisfaction? What are the constraints on building this type of system? What are the resource-consumption characteristics of various processes (including the optimization process) and how do they interact? Architecture: What are the various architectural structures that can be used to provide dynamic allocation of resources based on user preference? Is it possible to prescribe architectural designs for different types of mobile devices, based on the desired characteristics of those systems?
To aid in our research we are building a test-bed simulator that simulates the various components of a mobile device, the user, and the environment in which the mobile system is operating. The problem of creating such architectures is challenging because the utility that the user gets from the system can change with respect to the changing environment. At one part of the day a user might desperately want to receive the latest download of sports scores or Wall Street numbers from the Web, and at another point this same user might have an important voice call to make and would like all resources to be diverted from other tasks to be concentrated on this one high-priority task. The device has to adapt to the changing needs of the user. For this reason, it seems crucial to have a simulator in which different architectural choices can be compared before building the system itself. In the final mobile system, such changing needs would either require a change in the scheduling algorithm or even a change in the control and data flow across components; in the simulator they require only a change of an initialization file.
The purpose of the test bed is manifold:
As shown in Figure 1, the test bed allows a variety of resources to be specified (in this case CPU, memory, network bandwidth, and battery). The test bed further allows a user to specify an architectural configuration of these resources, along with the tasks that use them. In this way, changing the architecture of a simulated system is as easy as changing a simple specification file.
Figure 1: The AAMS Test Bed in Configuration Mode
During execution, the test bed executes a script, which is also specified by the user, and the results of the simulation are updated in real time or at any rate that a user specifies. A portion of a sample run is shown in Figure 2.
Figure 2: The AAMS Test Bed Displaying an Execution Log
In addition to scripted events, the test bed supports the generation of stochastic events, such as changes in environmental conditions and new user requests. This allows test runs to be more realistic and removes the burden on the user to specify every detail of a simulation.
We feel that this test bed will be a valuable tool in exploring the design space surrounding adaptive mobile systems. We are currently implementing the test bed and expect to be testing it on real-world examples within the next four months.
Rick Kazman is a Senior Member of the Technical Staff at the SEI. His primary research interests are software architecture, design and analysis tools, software visualization, and software engineering economics. He is the author of over 50 papers and co-author of several books, including Software Architecture in Practice and Evaluating Software Architectures: Methods and Case Studies.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.