Self-Managing Situated Computing (SMScom)



Index



What is SMScom
Why SMScom
Possible Scenarios
Main Research Challenges
Key Contributions
Main Risks
References


What is SMScom



Software is the key enabling technology of our society. Since the early 1970s, there has been a continuous progress in the science and engineering of software, which led to better quality of products. Today, however, emerging requirements are challenging our current knowledge, and require a shift from the incremental improvements we have experienced in the past to radical changes to the way software is conceived, developed, and operated. In particular: Software development and operation are increasingly decentralized. Applications are composed dynamically out of parts that are developed and operated by independent parties. Requirements changes ask for continuous software adaptation and evolution. The infrastructures on which applications run are fully distributed. Technologies like RFID tags, wireless sensors, and embedded devices imply that the infrastructure can change dynamically both in physical and in logical structure. The so-called Internet of Things is fostering a situation where computing power and connectivity are not only possible any-time and any-place, but also for any-thing.
As a consequence, software must behave in a situational, self-managing manner. The term situational indicates that software is built to address a particular situation, problem, or challenge, and behaves according to the evolving situation in which it operates. The term context is also used with a similar meaning, although often with a narrower scope. Examples of situations are: the type of user (its preferences, its knowledge, ...), the physical environment (the current location of the executing environment), the computational units that populate the environment at any given time, the devices on which they may run, the environmental conditions (like temperature, light, ...). We assume that situational changes are frequent, even continuous, and may require adaptation as the application is running and offering a service. This requires the software to be self-managing. Thus, situational software applications are not static entities, but they must be able to self-adapt to changeable external conditions. Indeed, context-awareness and self-adaptation are central concepts of SMScom, along with the idea of a control loop that propagates the sensed information about situation changes back to a change in the software.
SMScom is a software engineering research project. As for any genuine engineering research, it aims at providing a sound and systematic approach to developing practical and useful products. As any far-looking engineering research, it is expected to provide radical innovations. Radical innovations come in two flavors: by pushing some emerging requirements to their extreme and by revisiting through them, in a radical manner, the way we today develop and operate software.
The requirements that motivate SMScom are already emerging in many crucial real-world cases, and examples of situational applications are already being developed. Research efforts have also been directed to such fields as self-adaptive [1], context-aware [2], or autonomic software [3] and pervasive computing [4]. We argue, however, that at this stage most efforts are ad-hoc, and we miss a coherent global picture. We know how to deal with specific problems, but we lack general methods.
SMScom will develop a consistent, integrated, and homogenous set of methods and tools for the design, validation, and operation of dependable self-managing situational software. According to [5], the term dependability is used to collectively identify non-functional requirements like availability, reliability, safety, and security.
SMScom aims at providing a holistic approach to self-managing situational computing. Our work will be rooted into an underlying theory of situational computing, upon which we will develop unified engineering methods and tools to develop dependable self-managing situational software applications.
An abstract view of our approach is shown in Fig. 1. The shaded boxes indicate the external parts of the environment that affect the SMScom world, because of their possible continuous changes. We assume that changes in the external world are captured and made available to the SMScom world through (abstract) sensors. User goals, along with contextual information provided by the sensors, determine the situations, based on which the existing computational units that are part of the environment are selected to form assemblies (or compositions) that are run as applications that satisfy the goals in a situated manner. The effect of the running system, in turn, generates changes in the external environment and in users' goals, which may be further sources of changes in the application. The proposed research does not focus on the development of individual computational units. Rather, it assumes that the environment is populated by a large number of computational units that may be assembled to provide the required application that fulfills the goals. Such computational units may be services that are offered and run by providers or components that may be downloaded. The focus of the research is on the adaptive composition. However, a certain composition may in turn be viewed as a composite computational unit, which may become part of further compositions.
The proposed research will focus primarily on different methods to achieve the required compositions in a fully automated way. It will also support human-directed compositions via suitable design aids, and combinations thereof.

Figure 1. Our Approach

Figure 1 shows that the traditional idea of a "software application" in SMScom becomes broader and encompasses a set of loosely coupled software components (services) that discover each other-given the particular situation and may cooperate just for the time needed for the fulfillment of a given user goal.

Return to index


Why SMScom



The need for a sound software engineering approach for situational software is motivated by two important trends that gained more and more momentum over the last years:
As a consequence, applications are more and more distributed, smaller and smaller devices are involved in the computation, and different communication protocols are provided by the infrastructure. Distributed applications are of course not new, but the scale, diversity, and requirements of the system we deal with are new, and existing approaches do not scale up to the current and future needs.
In terms of scale, we wish to deal with systems composed by a large number of nodes, as in the case of sensor networks and tags. Such systems are intrinsically heterogeneous-in terms of both nodes and communication infrastructures. The requirements we deal with specify behaviors that depend on continuous situational changes. The application must accommodate them automatically and seamlessly.
Finally, we will focus on systems that ask not only for high flexibility and continuous change, but also high dependability. This is another key challenge we will investigate in our research. According to conventional software engineering approaches, there are trade-offs between achieving flexibility and dynamic change, on one side, and dependability (and security) on the other. SMScom aims at reconciling them by keeping an explicit formal definition of dependability properties that must be assured by the system and using and enforcing it throughout all stages (from system design to operation).

Return to index


Possible Scenarios



During the project we will choose a number of reference scenarios to drive and help focus our research. The scenarios are not meant to be new: they are actually already investigated and solutions have been provided. However, as we mentioned, solutions are ad-hoc. Our purpose is to challenge the proposed general methodology to assess its potential benefits and validity. We briefly report here on some potential cases.
Consider the complexity involved in a public transportation system in a modern metropolis. Several (largely unrelated) organizations interact in order to produce value for their users, stakeholders, and even the general public not directly involved in the transportation services. Correspondingly, a plethora of information sources is available and people want to use them according to their availability and current goals. For example, a passenger at the bus stop could be interested in the data about itineraries and traffic, in order to plan her trip on her mobile phone. The bus stop and users are supposed to work together only for a limited amount of time, the elements (components) that define the software assembly (application) vary quite frequently, and the information the bus stop provides must be tailored on passengers' destinations and profiles. Users might also prefer trip data be presented on their mobile devices or displayed on the big screen near the bus stop and if too many passengers want their data on the display, the system must find suitable solutions to present them. Instead, bus drivers may be interested in traffic jams on their route and advice on alternatives: rerouting, however, would be possible only if no one is waiting at the skipped stops. We can also think of environmental monitoring applications, able to sense the air and react automatically if pollution becomes too high. Many reactions are actually possible, including re-routing traffic from the most polluted areas, but they should be selected with respect to the different actors involved. A traffic control application could consider the vehicles that enter and leave a specific area as active entities that signal their position, receive information about traffic congestions, and decide the best route to take. The same vehicles may also discover some new services provided by the context (e.g., availability of parking lots, automatic toll systems, or tourist information).
The concepts of situational software developed by SMScom can be applied also in other relevant practical cases, from the automation of the appliances of everyday use to assisted living for elderly or impaired people. Situations evolve continuously, and the supporting software cannot be re-designed, re-implemented, and re-configured every time. If the pathologies of an elder person become worse, doctors might decide they want to monitor new vital parameters and this information must be analyzed and sent to them automatically. A similar adaptation pattern may be exploited when a handicapped person, who uses a wheelchair, buys a new DVD player and wants to control it remotely through the joystick used to control his/her chair.
Since this is a research proposal, these are only a few examples of where the methods and tools targeted by SMScom may address societally relevant problems. SMScom does not identify test-beds and scenarios a-priori to demonstrate its applicability. Different case studies will be selected and used as appropriate throughout the project. The group, however, is also active in other research projects that ensure interaction with industry, government, and public administrations on more application-oriented testbeds. In particular, the group participates in FP7 projects like the SeCSE, Cascadas, SLA@SOI, Q-Impress, and in the S-CUBE research network, and through them can interact with the EU platform on services NESSI, which coordinates most of the advanced European initiatives in the area. Through this rich network of cooperations, SMScom will benefit both in terms of problem areas to focus on, trial experiments, and collaborations.

Return to index


Main Research Challenges



SMScom will focus on all lifelong aspects of a situational application. The expected results will be an integrated set of methods and prototype support tools. In particular we will focus on:
Specification. Specification comes into the picture because we need to formally describe SMScom entities, such as goals, abstract sensors, computational units, and devices. The specification must be formal, to support the mathematical reasoning that is necessary to ensure the desired levels of dependability and automation. Based on the explicitly formulated goals, which express why an application has to be reified and what it is expected to fulfill, SMScom will support the identification of the intentions, upon which computational units are selected and combined (possibly through local adaptations) to yield assemblies.

Verification. Verification is key to dependability. We will address verification of both the functional and non-functional properties against the goals. Moreover, since SMScom considers continuously evolving systems, we will consider verification as a lifelong effort. In the ideal, but extreme, case in which the application is composed in a fully automated way, verification is only performed at run time, to check that everything works as specified when the assembly was formed. Run-time data that indicate possible changes in the computational units, in the hosting devices, in the goals, or in the external world (captured by sensors), which may invalidate the correctness of the resulting assembly, must be kept, analyzed, and then fed back to the SMScom process that (partially) re-generates the assembly. Beside this extreme case we consider also more traditional situations, involving human intervention at design time, which require design-time verification to be also performed. In general, SMScom will explore the seamless integration of the design-time and run-time verification of the correctness of assemblies.

Architectural composition mechanisms. SMScom will explore fully automated mechanisms to support compositions. On the other hand, we expect that full automation will work in rather specific and restricted domains. Therefore we will explore the entire range of options, from full automation to designer-specified compositions. In the latter case, we will explore different composition architectures: from those that require a logically global coordination to those that are fully decentralized.

Change mechanisms. SMScom primarily deals with systems that dynamically change over time and must continue to offer service as changes occur. Adaptation to change can be reified in many different ways: from predefined applications, whose adaptability is anticipated, and limited to some variation points (as in product line architectures), to (service) aggregations fully created at runtime, whose components are discovered and assembled dynamically by means of planning techniques.

Middleware. Adaptation in a heterogeneous, dynamic, and largely distributed environment like the one we envision is hard to obtain without the support of appropriate middleware abstractions, which could ease the task of programmers. Such abstractions must support both the architectural styles and the change mechanisms mentioned above. Moreover, the middleware itself must be able to adapt to changes in the external environment to offer its services in every possible situation.

Sensing and actuating environment. In SMScom users are expected to interact with an augmented environment, which provides both sensing and actuating capabilities. As soon as a situation change is detected, possibly because new devices enter the scene while others leave, the new situation can provide both new inputs for the components already in use, and completely new capabilities. Moreover, sensors, actuators, and embedded devices in general, may also become the computing platforms to run dedicated components (services), which may become part of the application (possibly for a limited amount of time). Consequently, new situations may offer new computational units that must be taken into consideration if we want to allow users to be able to exploit the best "tool" for the goals they want to tackle in a particular situation.

Security. Security issues are of paramount importance among other dependability attributes. Situational software systems can be successful only if they operate in a secure manner, by preserving privacy and trust among the involved parties. Since in general context has an impact on security policies, the services provided by the system and the authorizations granted should adapt themselves to the current situation and revoked accordingly. Moreover, privacy becomes a further constraint since context information has often a personal character that must be preserved accordingly.

Return to index


Key Contributions



SMScom will investigate innovative solutions in different research areas. Although new ideas (and research directions) will be identified in the course the project, SMScom will explore the following main research areas:
Research results will be described in technical papers, which will be submitted to mainstream conferences and archival journals. We will also contribute to the organization of specialized international workshops focusing on the themes addressed by SMScom. Dissemination will also be achieved through tutorials presented at major international conferences and through advanced graduate courses taught at Politecnico di Milano and at Summer Graduate Schools. The software products developed by the project will be offered freely on the Web, and the most interesting ones will be promoted to real open-source projects.

Return to index


Main Risks



Since SMScom is an ambitious and far-looking research project, risks are part of its intrinsic nature and cannot be avoided. Risks, however, can be mitigated by adopting sound research management practices, which ensure continuous, careful assessment of the feasibility and progress of the various steps. The risks intrinsic in a project like SMScom can be summarized in three main classes, for which we identify possible contrasting strategies:

Technological risks. Advances in theoretical work can be slower than the actual evolution of computing and communication technologies. This problem is typical of engineering research in rapidly evolving areas, where the need for sound design methods is challenged by continuous changes in technology. Risks can be mitigated by adopting an iterative and incremental approach for the development of SMScom, and by a thorough evaluation of the obtained results against the advances in the technological context at the end of each iteration. In the proposal we chose 18-month iteration loops. The other important element is the adoption and release of open(-source) solutions, to always keep the project as open as possible and avoiding the adoption of specific solutions that might result in unnecessary constraints.


Integration risks. The necessary breakdown of research into manageable and measurable increments should not violate the conceptual integrity of the SMScom holistic approach. The risk is to work hard and deliver great single components that do not work together. Here we need to balance between the necessary freedom, which is intrinsic in visionary research, with the need of achieving the long-term goal, which is based on a holistic vision. Our plan is to mitigate risks by anticipating the integration plans of each iteration. They will be in charge of setting the technological and architectural constraints, but also of envisioning suitable test beds (case studies) to set the reference scenario for each research activity.

Reality risks. Often research solutions work great in limited experimental settings, but do not scale to realistic contexts. SMScom aims at delivering research whose transformation into realistically usable solutions can be convincingly demonstrated. SMScom will produce research prototypes, not products, but all the outcomes must be good enough at sufficiently demonstrating the innovation, soundness, and feasibility of the proposed solutions. Again, we plan to exploit the iterative and incremental approach introduced above to mitigate reality risks. The idea is to carefully plan each iteration by clearly defining goals, requirements, and metrics to evaluate them. Each iteration is supposed to end with the evaluation of obtained results, the identification of further requirements for the next phase, and the identification of corrective actions to keep the project on the track of "realistic" results and solutions.

Return to index


References



  1. M. Baldauf, S. Dustdar, F. Rosenberg, A Survey on Context-Aware Systems, International Journal of Ad Hoc and Ubiquitous Computing, January 2006
  2. P. Oreizy, M.M. Gorlick, R.N. Taylor, D. Heimbigner, G. Johnson, N. Medvidovic, A. Quilici, D.S. Rosenblum, A.L. Wolf, An Architecture-Based Approach to Self-Adaptive Software, IEEE Intelligent Systems, vol. 14, no. 3, pages 54-62. May/June 1999
  3. P. Horn. Autonomic computing: IBM's perspective on the state of information technology. IBM TJ Watson Labs., October 2001
  4. IEEE Pervasive Computing, IEEE Computer Society.
  5. A. Avizienis, J.-C. Laprie, B. Randell, Fundamental Concepts of Dependability, Research Report No 1145, LAAS-CNRS, April 2001.

Return to index