Self-adaptive smart spaces by proactive means–end reasoning

Abstract

The ability of a system to change its behavior at run-time is one of the foundations for engineering intelligent environments. The vision of computing systems that can manage themselves is fascinating, but to date, it presents many intellectual challenges to face. Run-time goal-model artifacts represent a typical approach to communicate requirements to the system and open new directions for dealing with self-adaptation. This paper presents a theoretical framework and a general architecture for engineering self-adaptive smart spaces by breaking out some design-time constraints between goals and tasks. The architecture supports software evolution because goals may be changed during the application lifecycle. The architecture is responsible for configuring its components as the result of a decision-making algorithm working at the knowledge level. The approach is specifically suitable for developing smart space systems, promoting scalability and reusability. The proposed architecture is evaluated through the execution of a set of randomized stress tests.

This is a preview of subscription content, access via your institution.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7

Notes

  1. 1.

    Available, as open source, at https://github.com/icar-aose/musa_2

References

  1. 1.

    Abeywickrama DB, Bicocchi N, Zambonelli F (2012) Sota (2012) Towards a general model for self-adaptive systems. In: Enabling technologies: infrastructure for collaborative enterprises (WETICE), 2012 IEEE 21st international workshop, IEEE, pp 48–53

  2. 2.

    Allen JF (1983) Maintaining knowledge about temporal intervals. Commun ACM 26(11):832–843

    Article  MATH  Google Scholar 

  3. 3.

    Allen JF (1991) Planning as temporal reasoning. KR 91:3–14

    MathSciNet  MATH  Google Scholar 

  4. 4.

    Augusto JC, Callaghan V, Cook D, Kameas A, Satoh I (2013) Intelligent environments: a manifesto. Hum Centric Comput Inf Sci 3(1):12

  5. 5.

    Baresi L, Guinea S (2011) A3: self-adaptation capabilities through groups and coordination. In: Proceedings of the 4th India software engineering conference, ACM, New York, pp 11–20

  6. 6.

    Baresi L, Pasquale L, Spoletini P (2010) Fuzzy goals for requirements-driven adaptation. In: Requirements engineering conference (RE), 2010 18th IEEE international, IEEE Press, Sydney, pp 125–134

  7. 7.

    Basili VR (1990) Viewing maintenance as reuse-oriented software development. Softw IEEE 7(1):19–25

  8. 8.

    Bennaceur A, France R, Tamburrelli G, Vogel T, Mosterman PJ, Cazzola W, Costa FM, Pierantonio A, Tichy M, Akşit M et al (2014) Mechanisms for leveraging models at runtime in self-adaptive software. Models@ run. time. Springer, pp 19–46

  9. 9.

    Biere A, Heule M, van Maaren H (2009) Handbook of satisfiability, vol 185. IOS Press, Amsterdam

    MATH  Google Scholar 

  10. 10.

    Blair G, Bencomo N, France RB (2009) Models@ run. time. Computer 42(10):22–27

    Article  Google Scholar 

  11. 11.

    Blanchet W, Stroulia E, Elio R (2005) Supporting adaptive web-service orchestration with an agent conversation framework. In: Web services, ICWS 2005. Proceedings 2005 IEEE International Conference, IEEE

  12. 12.

    Bordini RH, Hübner JF, Wooldridge M (2007) Programming multi-agent systems in AgentSpeak using Jason, vol 8. Wiley, Hoboken

    Book  MATH  Google Scholar 

  13. 13.

    Braberman V, D’Ippolito N, Kramer J, Sykes D, Uchitel S (2015) Morph: a reference architecture for configuration and behaviour self-adaptation. arXiv:1504.08339

  14. 14.

    Bratman ME, Israel DJ, Pollack ME (1988) Plans and resource-bounded practical reasoning. Comput Intell 4(3):349–355

    Article  Google Scholar 

  15. 15.

    Bresciani P, Perini A, Giorgini P, Giunchiglia F, Mylopoulos J (2004) Tropos: an agent-oriented software development methodology. Auton Agents Multi-Agent Syst 8(3):203–236

    Article  MATH  Google Scholar 

  16. 16.

    Brun Y, Serugendo GDM, Gacek C, Giese H, Kienle H, Litoiu M, Müller H, Pezzè M, Shaw M (2009) Engineering self-adaptive systems through feedback loops. Softw Eng Self-Adapt Syst, Springer, pp 48–70

  17. 17.

    Chapin N, Hale JE, Khan KM, Ramil JE, Tan WG (2001) Types of software evolution and software maintenance. J Softw Maint Evol Res Pract 13(1):3–30

  18. 18.

    Cheng BHC, De Lemos R, Giese H, Inverardi P, Magee J, Andersson J, Becker B, Bencomo N, Brun Y, Cukic B et al (2009) Software engineering for self-adaptive systems: a research roadmap. Softw Eng Self Adapt Syst, Springer, pp 1–26

  19. 19.

    Coen MH et al (1998) Design principles for intelligent environments. In: AAAI ‘98/IAAI ’98 Proceedings of the fifteenth national/tenth conference on Artificial intelligence/Innovative applications of artificial intelligence, American Association for Artificial Intelligence, Menlo Park, pp. 547–554

  20. 20.

    Corcho O, Gómez-Pérez A (2000) A roadmap to ontology specification languages. Knowl Eng Knowl Manag Methods Models Tools 2000:80–96

  21. 21.

    Cossentino M, Dalle Nogare D, Giancarlo R, Lodato C, Lopes S, Ribino P, Sabatucci L, Seidita V (2014) GIMT: a tool for ontology and goal modeling in BDI multi-agent design. In: Workshop “Dagli Oggetti agli Agenti”

  22. 22.

    Cossentino M, Gaud N, Hilaire V, Galland S, Koukam A (2010) ASPECS: an agent-oriented software process for engineering complex systems. Auton Agents Multi-Agent Syst 20(2):260–304

    Article  Google Scholar 

  23. 23.

    Cossentino M, Lodato C, Lopes S, Sabatucci L (2015) Musa: a middleware for user-driven service adaptation. In: Proceedings of the 16th workshop “From objects to agents”, Naples, 17–19 June 2015

  24. 24.

    Dalpiaz F, Borgida A, Horkoff J, Mylopoulos J (2013) Runtime goal models: keynote. In: Research challenges in information science (RCIS), 2013 IEEE seventh international conference, IEEE, pp 1–11

  25. 25.

    Dalpiaz F, Giorgini P, Mylopoulos J (2013) Adaptive socio-technical systems: a requirements-based approach. Requir Eng 18(1):1–24

    Article  Google Scholar 

  26. 26.

    De Lemos R, Giese H, Müller H, Shaw M, Andersson J, Litoiu M, Schmerl B, Tamura G, Villegas NM, Vogel T et al (2013) Software engineering for self-adaptive systems: a second research roadmap. Springer. Softw Eng Self Adapt Syst II:1–32

  27. 27.

    Dean TL, Kambhampati S (1997) Planning and scheduling. In: CRC handbook of computer science and engineering. CRC Press, Boca Raton, pp 614–636

  28. 28.

    Fikes RE, Nilsson NJ (1972) Strips: a new approach to the application of theorem proving to problem solving. Artif Intell 2(3):189–208

    MATH  Google Scholar 

  29. 29.

    Ghezzi C, Pinto LS, Spoletini P, Tamburrelli G (2013) Managing non-functional uncertainty via model-driven adaptivity. In: Proceedings of the 2013 international conference on software engineering, IEEE Press, Piscataway, pp 33–42

  30. 30.

    Gomaa H, Hashimoto K (2012) Dynamic self-adaptation for distributed service-oriented transactions. In: Software engineering for adaptive and self-managing systems (SEAMS), 2012 ICSE Workshop, IEEE Press, Piscataway, pp 11–20

  31. 31.

    Gorlick M, Razouk RR (1991) Using weaves for software construction and analysis. In: Software engineering. Proceedings 13th international conference, IEEE, pp 23–34

  32. 32.

    Gu T, Wang XH, Pung HK, Zhang DQ (2004) An ontology-based context model in intelligent environments. In: Proceedings of communication networks and distributed systems modeling and simulation conference, San Diego, vol 2004, pp 270–275

  33. 33.

    Guarino N, Carrara M, Giaretta P (1994) Formalizing ontological commitment. AAAI 94:560–567

    Google Scholar 

  34. 34.

    Guizzardi R, Franch X, Guizzardi G (2012) Applying a foundational ontology to analyze means-end links in the i framework. In: Research challenges in information science (RCIS), 2012 sixth international conference, IEEE, pp 1–11

  35. 35.

    Harker SDP, Eason KD, Dobson JE (1993) The change and evolution of requirements as a challenge to the practice of software engineering. In: Requirements engineering. Proceedings of IEEE international symposium, IEEE, pp 266–272

  36. 36.

    Jureta IJ, Borgida A, Ernst NA, Mylopoulos J (2014) The requirements problem for adaptive systems. ACM Trans Manag Inf Syst TMIS 5(3):17

  37. 37.

    Kephart JO, Chess DM (2003) The vision of autonomic computing. Computer 36(1):41–50

    MathSciNet  Article  Google Scholar 

  38. 38.

    Kramer J, Magee J (2007) Self-managed systems: an architectural challenge. In: Future of software engineering, 2007. FOSE’07, IEEE, pp 259–268

  39. 39.

    Lamport L (1994) The temporal logic of actions. ACM Trans Progr Lang Syst TOPLAS 16(3):872–923

    Article  Google Scholar 

  40. 40.

    Lesperance Y (1989) A formal account of self-knowledge and action. IJCAI, Citeseer, pp 868–874

  41. 41.

    Lowe EJ (2002) A survey of metaphysics. Oxford University Press, Oxford

    Google Scholar 

  42. 42.

    Moore RC (1979) Reasoning about knowledge and action. PhD thesis, Massachusetts Institute of Technology

  43. 43.

    Morandini M, Penserini L, Perini A (2008) Towards goal-oriented development of self-adaptive systems. In: Proceedings of the 2008 international workshop on software engineering for adaptive and self-managing systems, ACM, New York, pp 9–16

  44. 44.

    Morandini M, Penserini L, Perini A (2009) Operational semantics of goal models in adaptive agents. In: Proceedings of the 8th international conference on autonomous agents and multiagent systems, International Foundation for Autonomous Agents and Multiagent Systems, vol 1, ACM, Richland, pp 129–136

  45. 45.

    Newell A (1982) The knowledge level. Artif Intell 18(1):87–127

    MathSciNet  Article  Google Scholar 

  46. 46.

    O’Brien PD, Nicol RC (1998) Fipa—towards a standard for software agents. BT Technol J 16(3):51–59

    Article  Google Scholar 

  47. 47.

    Oreizy P, Gorlick MM, Taylor RN, Heimbigner D, Johnson G, Medvidovic N, Quilici A, Rosenblum DS, Wolf AL (1999) An architecture-based approach to self-adaptive software. IEEE Intell Syst 3:54–62

  48. 48.

    Oreizy P, Medvidovic N, Taylor RN (1998) Architecture-based runtime software evolution. In: Proceedings of the 20th international conference on software engineering, IEEE Computer Society, Washington, pp 177–186

  49. 49.

    Patikirikorala T, Colman A, Han J, Wang L (2012) A systematic survey on the design of self-adaptive software systems using control engineering approaches. In: Software engineering for adaptive and self-managing systems (SEAMS), 2012 ICSE workshop, pp 33–42

  50. 50.

    Pistore M, Marconi A, Bertoli P, Traverso P (2005) Automated composition of web services by planning at the knowledge level. IJCAI 19: 1252–1259

  51. 51.

    Rao AS (1996) Agentspeak (l): BDI agents speak out in a logical computable language. In: Agents breaking away, Springer, pp 42–55

  52. 52.

    Ribino P, Cossentino M, Lodato C, Lopes S, Sabatucci L, Seidita V (2013) Ontology and goal model in designing BDI multi-agent systems. WOA@ AI* IA 1099:66–72

    Google Scholar 

  53. 53.

    Rouvoy R, Barone P, Ding Y, Eliassen F, Hallsteinsen S, Lorenzo J, Mamelli A, Scholz U (2009) Music: middleware support for self-adaptation in ubiquitous and service-oriented environments. Softw Eng Self Adapt Syst, Springer, pp 164–182

  54. 54.

    Sabatucci L, Cossentino M (2015) From means-end analysis to proactive means-end reasoning. In: Proceedings of 10th international symposium on software engineering for adaptive and self-managing systems, Florence, 18–19 May 2015

  55. 55.

    Sabatucci L, Cossentino M, Lodato C, Lopes S, Seidita V (2013) A possible approach for implementing self-awareness in Jason. EUMAS, Citeseer, pp 68–81

  56. 56.

    Sabatucci L, Lodato C, Lopes S, Cossentino M (2013) Towards self-adaptation and evolution in business process. AIBP@ AI* IA, Citeseer, pp 1–10

  57. 57.

    Sabatucci L, Lodato C, Lopes S, Cossentino M (2015) Highly customizable service composition and orchestration. In: Dustdar S, Leymann F, Villari M (eds) Service oriented and cloud computing. Lecture notes in computer science, vol 9306. Springer, Berlin, pp 156–170

  58. 58.

    Sabatucci L, Ribino P, Lodato C, Lopes S, Cossentino M (2013) Goalspec: a goal specification language supporting adaptivity and evolution. Eng Multi-Agent Syst, Springer, pp 235–254

  59. 59.

    Saeki M (2010) Semantic requirements engineering. Intent Perspect Inf Syst Eng, Springer, pp 67–82

  60. 60.

    Souza VES, Lapouchnian A, Mylopoulos J (2012) (Requirement) evolution requirements for adaptive systems. In: Software engineering for adaptive and self-managing systems (SEAMS), 2012 ICSE workshop, pp 155–164

  61. 61.

    Sycara K, Widoff S, Klusch M, Jianguo L (2002) Larks: dynamic matchmaking among heterogeneous software agents in cyberspace. Auton Agents Multi-Agent Syst 5(2):173–203

    Article  Google Scholar 

  62. 62.

    Whittle J, Sawyer P, Bencomo N, Cheng BH, Bruel JM (2009) Relax: incorporating uncertainty into the specification of self-adaptive systems. In: Requirements engineering conference. RE’09. 17th IEEE international, IEEE, pp 79–88

  63. 63.

    Wooldridge MJ (2000) Reasoning about rational agents. MIT Press, Cambridge

    MATH  Google Scholar 

  64. 64.

    Yu E (2011) Modelling strategic relationships for process reengineering. Soc Model Requir Eng 11:2011

    Google Scholar 

  65. 65.

    Zambonelli F, Castelli G, Mamei M, Rosi A (2014) Programming self-organizing pervasive applications with SAPERE. Intell Distrib Comput VII, Springer, pp 93–102

Download references

Author information

Affiliations

Authors

Corresponding author

Correspondence to Luca Sabatucci.

Appendix: engineering the exhibition center with MUSA

Appendix: engineering the exhibition center with MUSA

MUSA (Middleware for User-driven Service Adaptation) [23] is a multi-agent system for the composition and orchestration of services in a distributed and open environment. It aims at providing run-time modification of the flow of events, dynamic hierarchies of services, and integration of user preferences together with a system for run-time monitoring of activities that is also able to deal with unexpected failures and optimization.

The middlewareFootnote 1 is coded in JASON [12], a declarative programming language based on the AgentSpeak language [51] and the BDI theory [14]. The state of an agent together with its knowledge of the operative environment is modeled through its belief base, expressed by logical predicates. Desires are states the agent wants to attain according to its perceptions and beliefs. When an agent adopts a plan, it transforms a desire to an intention to be pursued.

In JASON the specification of plans is strictly connected to the desire that triggers its execution. Therefore, we developed a high-level language (GoalSPEC [58]) with the twofold aim of (1) allowing the user to specify requirements in the form of goals and (2) supporting the idea of decoupling what the system has to do, and how it must do that.

The theory of self-knowledge and action [42] asserts an agent achieves a goal by doing some actions if the agent knows what the action is and it knows that doing the action would result in the goal being satisfied [40]. Therefore, we also defined a high-level language to specify system’s capabilities.

Since software agents are deployed in a distributed environment, MUSA implements a distributed version of Algorithms 1 and 2. The knowledge level is supported by goals’ and capabilities’ specifications that are translated from high-level languages into agent’s beliefs [55]. A configuration represents a contract among the agents specifying how to collaborate. Therefore, service composition is obtained at run-time, as the result of a self-organization phenomenon.

In the following, we detail the ingredients needed to achieve our purpose: the way we depict the problem domain using an ontology, a goal specification language that refers to ontological elements as keys for grounding the goals on the problem and, finally, a capability language that supports the separation between the abstract description and the concrete implementation.

The domain ontology description

Working at the knowledge level implies an ontology commitment between who develops Capabilities and who specifies Goals. An ontology is a specification of a conceptualization made for the purpose of enabling knowledge sharing and reuse [59]. An ontological commitment is an agreement to use a thesaurus of words in a way that is consistent with the theory specified by an ontology [33].

A Problem Ontology (PO) [21, 52] is a conceptual model (and a set of guidelines) used to create an ontological commitment to developing complex distributed systems [22]. This artifact aims at visualizing an ontology as a set of concepts, predicates, and actions and how these are related to one another. An example is shown in Fig. 8.

Fig. 8
figure8

Example of problem ontology for the exhibition center. Ontology elements represented without stereotypes are to be read as concepts by default

The metamodel of a PO artifact, inspired by the FIPA (Foundation for Intelligent Physical Agents) standard [46], is briefly summarized as follows:

  • a Concept is a general term commonly used in a broad sense to identify “anything about which something is said” [20] that has a unique meaning in a subject domain;

  • a Predicate is the expression of a property, a quality or a state of one (ore more) concept(s);

  • an Action is the cause of an event by an acting concept [41]);

  • a Position is a specialization of concept performing Actions;

  • finally, an Object represents physical or abstract things.

  • the relationship is-a (or is-a-subtype-of) defines which objects are classified by which class, thus creating taxonomies;

  • the relationship part-of (or the counterpart has-part) represents the structure by composition;

  • the relationship association establishes links between ontological elements.

A goal specification language

The GoalSPEC language [58] has been specifically designed for enabling runtime goal injection and software agent reasoning. It takes inspiration from languages for specifying requirements for adaptation, such as RELAX [62]. However, GoalSPEC is in line with Definition 2 and adopts a domain-independent core grammar with a basic set of keywords that may be extended with a domain ontology.

The main entity of the GoalSPEC language is the Goal that is wanted by some Subject and it is structurally composed of a Trigger Condition and a Final State. It is worth underlining that both Trigger Conditions and Final States must be expressed by using predicates defined in a domain ontology.

Some examples of GoalSPEC productions for the domain of the Exhibition Center are listed below. For a complete specification of the syntax of GoalSPEC, see  [58].

  1. 1.

    WHEN registered(Usr,Event) AND NOT attending(Urs,Event) THE system SHALL PRODUCE notification(Event,Usr)

  2. 2.

    BEFORE moving(Urs,Loc) AND exhibition_area(Loc) THE visitor SHALL PRODUCE moving(Urs,Reception) AND check-in(Urs)

We use uppercase for the keywords of the language, and lowercase for domain-specific predicates. Logical variables start with an uppercase letter. Goal 1 indicates that ‘if a visitor has registered for an event, the user will be notified about time-table until he goes to the event’. Goal 2 states that ‘A condition to enter the exhibition center area is to go to the reception and check-in’.

A capability specification language

There is an obvious need for a semantic-based language to describe agent capabilities in a common language in a way that (1) the agent knows how to execute the capability and (2) it knows the effects of executing it [42].

So far we use a refinement of LARKS [61] a language for advertisement and request for knowledge sharing used in the context of web services.

Fig. 9
figure9

A couple of capabilities described through the capability specification language

A Capability is made of two parts: an abstract description, and a concrete body implementation (a set of plans for executing the job). The abstract description is defined through the following fields: (1) Name: unique label used to refer to the capability, (2) Input/OutputParams: variables that is necessary to instantiate for the execution, (3) Constraints: structural constraints on input/output variables, (4) Pre/Post Condition: conditions that must hold in the current state of the world and in the final state of the world and finally, (5) Evolution: function \(evo:W \longrightarrow W\) as described in Section 2.2.

We do not provide any language for the body, leaving the choice of the specific technology to the developer. We frequently used Java to code this part of our capabilities because of the smooth integration with Jason on the one side and the flexibility in the invocation of web services on the other side.

Figure 9 shows two examples of capabilities. The Alert Sender capability that uses smartphones to advert about the event and provide alerts about the timetable. The second capability is the Cloud Calendar Check capability that interacts with a calendar application for retrieving information about an event timetable.

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Sabatucci, L., Cossentino, M. Self-adaptive smart spaces by proactive means–end reasoning. J Reliable Intell Environ 3, 159–175 (2017). https://doi.org/10.1007/s40860-017-0047-9

Download citation

Keywords

  • Self-adaptive systems
  • Software architecture
  • Smart spaces