Self Adaptive Software: A Position Paper Robert Laddaga MIT CSAIL
[email protected]
Paul Robertson Dynamic Object Language Labs
[email protected]
Abstract 1. In this paper, we define Self Adaptive Software (SAS), discuss paradigms for implementing SAS, the core problem of self evaluation, discuss some applications, and indicate some area of future work.
1
Introduction
A definition of Self Adaptive Software was provided in a DARPA Broad Agency Announcement on Self Adaptive Software (BAA-98-12) in December of 1997: Self Adaptive Software evaluates its own behavior and changes behavior when the evaluation indicates that it is not accomplishing what the software is intended to do, or when better functionality or performance is possible. …This implies that the software has multiple ways of accomplishing its purpose, and has enough knowledge of its construction to make effective changes at runtime. Such software should include functionality for evaluating its behavior and performance, as well as the ability to replan and reconfigure its operations in order to improve its operation. Self Adaptive Software should also include a set of components for each major function, along with descriptions of the components, so that components of systems can be selected and scheduled at runtime, in response to the evaluators. It also requires the ability to impedance match input/output of sequenced components, and the ability to generate some of this code from specifications. In addition, DARPA seek this new basis of adaptation to be applied at runtime, as opposed to development/design time, or as a maintenance activity. The key aspects of this definition are that code behavior is evaluated or tested at runtime, that a negative test result leads to a runtime change in behavior, and that the runtime code includes the following things not currently included in shipped software:
2.
descriptions of software intentions (i.e. goals and designs) and of program structure; a collection of alternative implementations and algorithms (“a reuse asset base”).
There are two useful paradigms for utilizing Self Adaptive Software. One of these is a planning paradigm, and the other is the control paradigm. We discuss each in turn.
2
The Plan, Execute, Monitor, and Revise Paradigm
The first paradigm treats an application as a dynamic planning system. So, we imagine that the application doesn’t simply execute a specific set of algorithms, but instead plans its actions, then executes those actions. The plan would include tasks that evaluate how well the plan is executing, as well as the algorithmic tasks that are the core of the application. The plan itself is available for inspection, evaluation, and modification. Replanning can occur at runtime in response to a negative evaluation of the effectiveness of the plan, or its execution. The plan would treat computational resources such as hardware, communication capacity, and code objects (components) as resources that the plan can schedule and configure.
3
Writing Software that Executes “Closed Loop”
Under this paradigm, we design and code an application as a control system. The runtime software is treated like a factory, with inputs and outputs, and a monitoring and control facility that manages the factory. Evaluation, measurement and control systems are layered on top of the application, and manage reconfiguration of the system. This regulated behavior is served by explicit models of the operation, purpose and structure of the application. It is significantly more complex than standard control systems, since the effects of small changes are highly variable, and because the filtering and diagnosis of results before they can be treated as feedback or feedforward mechanisms is also very complex. Despite
the difficulties of applying control theory to such highly non-linear systems, there appears to be a very valuable set of insights to be exploited from control theory, including for example the concept of stability.
relatively few intuitions about the best way to trim the search space, so self evaluation technology can greatly help here.
4
5
Self Evaluating Software
A difficult problems for Self Adaptive Software is the problem of self evaluation[8]. It is often not clear that we can evaluate functionality and performance at runtime. Of course, some problems are easier to evaluate than others, and we can certainly try categorizing problems according to difficulty of self evaluation, and work initially on the easy problems. Let’s consider three classes of applications: constructive, analytic with ground truth available, and analytic without ground truth. Suppose a robot is attempting to reach a goal location, around a series of partially mapped obstructions. An example of a constructive task is to plan a route to the goal. Clearly, we can evaluate the plan based on its merits, in comparison to constraints and goals known when the program is written. Thus, doing self evaluation for these constructive programs is relatively straightforward. It is also somewhat less interesting, in that we already do some of this, and the payoff isn’t as great as with other categories. The harder task is that of actually moving to the goal location. If obstructions get in the way, we can still evaluate performance if we know our position relative to the goal, for example by having GPS or inertial guidance sensors on board. This is an example of an analytic problem with ground truth (our position relative to the goal) known. Most simple control system problems have this character, we have some means of sensing progress, and correcting behavior to improve progress. This is clearly a fertile area for Self Adaptive Software. The hardest task is similar to the second, but in this case we only have evidence about our position, not knowledge. This category is that of analytic problems without ground truth available. In this third class of applications, we can still use weight of evidence and probabilistic reasoning to evaluate performance at runtime. In fact, this kind of statistical evaluation is used as one of the ways we evaluate and operate such systems. Although evaluation is most difficult here, the payoff is also greatest, because these applications are among the most difficult, error prone, and brittle. They are characterized by unwieldy search spaces, and combinatorial difficulties. People tend to have
Applications of Self Adaptive Software
Self Adaptive Software is useful for dealing with all forms of embedded software. This includes robotics[1], manufacturing plants, avionics, vehicle control[3], sensor systems[5], and others. It is also valuable for image[6,7] and signal processing applications. It is also very useful for operating systems, middleware, installation, configuration and system management, and planning and scheduling systems. The area of pervasive computing involves many of the above application areas, including: computer based perception, sensor and control systems, middleware, configuration and planning and scheduling. As such, Self Adaptive Software is an ideal framework for building pervasive computing systems. Our own work has included vision, and vision applied to pervasive computing environments.
5.1
The GRAVA Architecture
Self
Adaptive
In this section, we present a system called GRAVA (for Grounded Reflective Adaptive Vision Architecture), as an example Self Adaptive Software System. GRAVA segments and labels images in a way that attempts to mimic the competence of a human expert. Communication model
MDL agent architecture
Segmentation algorithm
Statistical/MDL theorem prover
Patchwork parser
MDL clustering for model induction
Self-adaptive architecture
Legend Image segmentation And labeling program
Figure 1: GRAVA Logical Components
Supports
Figure 1 shows the logical components of the system along with the supporting relationships between the parts. We now sketch the roles of these components. Image Segmentation and Labeling Program To produce an image interpretation, a variety of tools need to be brought into play. First, the image is processed by various tools in order to extract texture or feature information. The selection of the right tools determines ultimately how good the resulting interpretation will be. Next, a segmentation algorithm is employed in order to produce regions with outlines whose contents are homogeneous with respect to content as determined by the chosen texture and feature tools. The segmentation algorithm also depends upon tools that select seed points that initialize the segmentation. The choice of tools to initiate the segmentation determines what kind of segmentation will be produced. Figure 2 shows an example segmented aerial image.
identification, or for contextual constraints---can lead to a poor image interpretation. The earlier the error occurs, the worse the resulting interpretation is likely to be.
5.1.1
Figure 2: Segmented Image Labeling the regions depends upon two processes. The first tries to determine possible designations for the regions by analyzing the pixels within the regions. The second is a statistical parser that attempts to parse the image using a 2D grammar. Our application currently doesn’t make use of the parse; but it could be used as the basis for further image interpretation. An important side effect for our application is that contextual information mobilized by the parse process enables good labels to be chosen for regions when there may be several ambiguous possibilities if one only looks at the pixels within the region. At any point, a bad choice of tool---for initial feature extraction, seed point identification, region
5.1.2 MDL Agent Architecture The problem of interpreting the real world is inherently ambiguous. A speech or vision program must select the most likely interpretation from the ambiguous candidates. Selecting the most likely interpretation is equivalent to selecting the interpretation with the minimum description length (MDL). We developed an agent architecture based on the MDL principle, and using MDL to apply higherlevel semantics. In the GRAVA system, as a result of the MDL architecture, cooperation between agents is an emergent property. 5.1.3 Statistical/MDL Theorem Prover If image understanding is defined in part as the problem of building a description of the scene depicted in the image, there is a need for some apparatus that can assemble such descriptions. While the components of the description are generated by special purpose agents, the task of building a structurally complex description out of these components is a problem that belongs to no one component. Similarly, the problem of synthesizing the program within the self adaptive framework described above requires some mechanism capable of assembling the individual agents into a form of program. We have developed a common structure-building component in the form of a theorem prover, and incorporated it into the architecture to address structure-building needs. The proof that has the shortest description length is judged to be the best proof. In this kind of proof, the theorem is a valid solution. In the case of a parse it is a syntactically correct structure for the set of lexical items (a lexical item in the case of a patchwork parse is a region). In the case of a program it is a legal program that addresses the details of the program’s design; in the case of a plan, the theorem would be a legal plan that addresses the details of the goal structure for which the plan seeks to find a solution. While the parse, program, or plan may be legal; none is guaranteed to be correct. The execution of the program may fail at some point. A plan may not succeed. Checkpoints are added to the generated structure whenever a component has a probability of success less than 1. These checkpoints provide a mechanism whereby self-adaptation can be initiated.
6
Future Work
In this section we describe two areas of important future work for Self Adaptive Software.
6.1
Unsupervised Learning
We have seen several places where it is possible to learn a new model without the need for an expert annotation. Typically this happens when smoothing has occurred. In the present system these “smoothed” models are not retained, and are given low probabilities so that they are not preferred over rules that do occur in the corpus. If the smoothed models were retained as if they had been encountered in the corpus they could participate in future interpretations. Each time the rule is used, whether it is an original model from the corpus or a model learned from a prior smoothing, its frequency of use could be tracked as the program encounters real data. Over time, the system would converge on a set of rules that match what the “real world” suggests it needs. The idea of a system that continues to converge after it has extracted a starting point from the annotated corpus is appealing. It potentially reduces the size of the corpus necessary to get a good system built. A robust system may be best constructed by inducing an initial set of models from a corpus followed by unsupervised training on representative images until the performance of the system is deemed to be adequate.
6.2
Dynamics of Self Adaptive Software
While self-adaptive software is being validated on a number of fronts, by a number of researchers by being applied to various research problems, there have been only modest attempts to understand the behavior[2] and semantics [4] of such systems and to reason about the dynamics of self-adaptive software. Of particular concern are issues of stability and convergence. Self-adaptive software in GRAVA takes the form of a control loop. Deviations from desired behavior detected within the reflective framework are used to re-synthesize the program code. The resulting program code may still differ from desired behavior requiring further self-adaptation. In a stable system this process will eventually converge towards the set point. In an unstable system the self-adaptation process will repeat indefinitely and will either not improve or even degrade (become further from the
set point). Since the synthesized code is produced by automated formal methods the correctness of the synthesized programs is not at issue---but stability is. Using the existing GRAVA architecture we are: 1. Incorporating tests for instability into the reflective framework that enables a system to automatically detect its own instability. 2. Building mechanisms to “break” an unstable behavior at runtime. 3. Develop design methodologies for selfadaptive software that either prohibit instability or ensure that adequate detection and recovery is available where instability can’t be prohibited.
7
References
[1] Grupen, R. 2000. Software mode changes for continuous motion tracking. In P. Robertson, R. L., and Shrobe, H., eds., Self-Adaptive Software. Springer-Verlag. pp161-180. [2] (Kokar 1999) Kokar, M. M.; Baclawski,K.; and Eracar, Y. A. Control Theory-Based Foundations of Self-Controlling Software. In IEEE Intelligent Systems (14) #3 May/June pp37-45. [3] Musliner, D.; Goldman, R.; Pelican, M.; and Krebsbach, K. 1999. Self-adaptive software for hard real-time environments. IEEE Intelligent Systems 14(4): pp23-29. [4] (Pavlovic 2000) Pavlovic, D. 2000. Towards semantics of self adaptive software. In P. Robertson, R. L., and Shrobe, H., eds., Self-Adaptive Software. Springer-Verlag. pp50-64. [5] Reece, S. 2000. Self-adaptive multi-sensor systems. In P. Robertson, R. L., and Shrobe, H., eds., Self-Adaptive Software. Springer-Verlag. pp224-241. [6] Robertson, P. and Brady, J. M., 1998. Adaptive Image Analysis for Aerial Surveillance. In IEEE Intelligent Systems (14) #3 May/June pp30-36 [7] Robertson, P. 1999. A Corpus Based Approach to the Interpretation of Aerial Images. In Proceedings IEE IPA99, IEE (Manchester). [8] Robertson, P., Laddaga, R., and Shrobe, H. Results of the First International Workshop on SelfAdaptive Software. In Self-Adaptive Software, Proceedings of the First International Workshop on Self-Adaptive Software, 2000, Lecture Notes in Computer Science 1936, Springer-Verlag, 2001.
