1 Introduction

Collective Adaptive Systems (CASs) are composed of distributed and heterogenous entities coming from both the real world and the back-end computer systems. Entities provide different system functionalities through their services. Services are defined as unique identifiable building blocks representing a concrete functionality in a larger, multi-service system. Implementing a functionality may involve interacting with other services through pre-defined protocols. At the same time, due to the high dynamism of the environment in which each service operates, the system must be able to re-configure its behavior at run-time in order to satisfy new users requirements and to fit new situations (i.e., unexpected and unlikely context changes). These systems ask for decentralized adaptations that can break the consistency of the whole collaboration. Thus, the adaptation must be itself collective: multiple services must adapt simultaneously to address a critical runtime condition, while preserving the collaboration and its benefits. In this paper we present DeMOCAS Footnote 1, a framework for the modeling and execution of service-based CASs. It includes mechanisms for services specialization and adaptation [4] and exploits the concept of Domain Object [3] as a way to model customizable and adaptable services. DeMOCAS is built around three main aspects: (i) dynamic settings (ii) collaborative nature of systems, and (iii) collective adaptation. To demonstrate DeMOCAS in action, we use a real-world scenario from the urban mobility domainFootnote 2.

2 Application Domain and Scenario

The scenario refers to a Multi-modal and Collaborative Urban Mobility System (UMS), in a smart-city context. The system’s goal is that of synergistically exploit the city services (e.g., transport, smart-card, online payment services), providing real-time, and customized mobility services, for the support of the whole travel duration. Moreover, the system is able to deal with dynamic context changes affecting its execution, by allowing the application of collective adaptation techniques. The system allows users to plan and execute a journey, on the basis of a set of required information (e.g., departure and arrival time and places) and preferences (e.g., preferred transport means). It arranges the set of suitable mobility alternatives (made by one or a composition of services), among which the user can choose (e.g., the flexibus, a transportation service that manages on-demand routes defined as a network of dynamic pickup points). At execution time, ensembles made by different entities (e.g., the flexibus company, the route manager, the flexibus driver, the passengers) are dynamically organized. Although autonomous in their execution, the ensemble’s member share common goals (e.g., being on time at the destination point). Ensembles play a fundamental role when the system needs to deal with context changes affecting its execution. The different entities can collaborate to reach the common good, in the cases in which adaptation needs arise (e.g., the flexibus route is blocked, a passenger is late to a pick-up point). If a collective adaptation is triggered, a decentralized and collective decision management strategy starts, where each entity does its best by offering its ability to handle specific problems. Furthermore, when an intra-ensemble adaptation (i.e., the problem is solved within the ensemble in which it arises) can not be solved, inter-ensembles adaptation (i.e., the problem is solved in the scope of more than one ensemble) can be performed.

3 Collective Adaptation Approach

In this Section we present the approach for modeling and execution of service-based CASs, as used in the implementation of DeMOCAS.

Application Model. DeMOCAS exploits a design for adaptation model, called Domain Object, defined with the purpose of modeling and executing service-based CASs. The model allows for the application of advanced techniques for dynamic adaptation (both local and collective), through specific constructs. Briefly, the system entities (e.g., system components, service providers) are modeled as domain objects (DOs from here on). Each DO implements its own behaviour (the core process), as well as the services (fragments) it provides. Both of them can be specified only partially, by defining abstract activities specified by their goals. At runtime, when a DO knows more about the context in which he is running, abstract activities are automatically refined with (one or a composition of) available fragments provided by other DOs. This also allows a DO to span its knowledge about the operational environment. Thus, the adaptive system results in a dynamic network of DOs. Moreover, over this dynamic network, ensembles are modeled as groups of autonomous DOs sharing common goals. For collective adaptation purposes, which are required to deal with adaptation needs spanning over the scope of a single DO, the model provides a set of solvers and handlers. While solvers model the ability of a DO to handle one or more issues, handlers are used to capture issues, during the nominal execution of a DO, and to trigger the appropriate solver.

Application Execution. DeMOCAS implements and shows the application of local and collective adaptations. The first one deals with the postponement of the concrete implementation of a service to the runtime phase (i.e., when the context is known). This kind of adaptation can be performed autonomously by a DO. The second, instead, is necessary to deal with unexpected changes in the environment and unpredictable behavior of the systems users and entities. For this kind of adaptation, a collaboration between DOs is required.

Local adaptation is performed at runtime through the refinement of abstract activities, by exploiting advanced techniques for dynamic and incremental service composition [1]. Moreover, through the refinement process, ensembles are formed. In the mobility domain, for instance, an ensemble can be made by the driver of a bus, its specific route and the passengers.

Collective adaptation comes into play to handle unpredictable changes, which usually affect different running entities. As a consequence, adaptation must be collective, for making the system resilient and avoid a halt. The collective adaptation is performed by exploiting the handlers and solvers constructs, and by associating a MAPE (Monitor, Analyze, Plan, Execute) loop [5] to each DO [2]. By monitoring the environment, handlers can both raise and–or catch issues. When an handler in a DO catches an issue, it calls the respective solver. A solver can solve the issue, or forward it outside the DO, if it is not able to provide a solution. In this case, a recursive procedure is triggered, leading to the construction of an issue resolution tree (as in Fig. 1, left side) in order to find a solution, if any. The chosen solution (the best one is selected in case of multiple solutions are available) will represent a path on the issue resolution tree. Moreover, it will be given by the union of the contributions coming for the solvers of the DOs involved in the resolution process. The best solution is eventually committed allowing the system to dynamically adapt and continue its execution. In Fig. 1 we show some panels of the Collective Adaptation Viewer of DeMOCAS. The Active Issue Resolutions table reports the issue resolution result for the issue Intense Traffic, triggered by a Flexibus Driver during its route execution, and it lists all the DOs involved in the issue resolution process. For each DO, the role, the handled issue, the issue status on its MAPE loop and the ensemble to which it belongs are given. The issue resolution tree, on the left side, relates to the Route Manager that owns the solver for the triggered issue. In the Ensembles Hierarchy panel, instead, the hierarchy of the ensembles involved in the issue resolution process, with their members, is graphically shown.

Fig. 1.
figure 1

Panels of the collective adaptation viewer of DeMOCAS.

Full size image

4 Implementation

DeMOCAS has been implemented by using Java as programming language, in an Eclipse developing IDE. From a design point of view, we report the DeMOCAS deployment diagram, in Fig. 2. The demonstrator is composed by five modules, namely Execution, Adaptation, AI Planning, Presentation and Model.

The Presentation module implements the DeMOCAS GUI, together with the functionalities allowing the scenario execution to be showed in the demonstrator interface. The graphical representation of the application domain is a map, on which the user can intuitively follow the evolution of the UMS scenario. The Presentation module is constantly synchronized with the Execution module.

Fig. 2.
figure 2

DeMOCAS deployment diagram.

Full size image

In the Model module, the Parser is responsible for loading the scenario files (i.e., the Domain Objects and the Ensembles) from the file system and parse it. The Process Model defines the basic building blocks for a process definition (e.g., input, output and abstract activities), while the Model, Entity and Ensemble Managers, are essentially devoted to handle the domain objects and ensembles life-cycles.

The Execution module comes into play once the scenario, modeled in terms of DOs, has been loaded and displayed. The Process Engine is in charge of simulating the execution of the core processes of the running DOs instances. When runtime problems occur, the Problem Handler creates requests for the Adaptation module.

The Adaptation module is called by the Process Engine. It tackles the refinement of abstract activities (local adaptations), as well as the issue resolutions (collective adaptations), through the Local Adaptation Manager and the Collective Adaptation Manager, respectively. The former is responsible for deriving the planning domain by driving the fragments selection and ranking (see [1]), according to the goal of the abstract activity and the specific execution context. The latter runs the collective adaptation algorithm, for the issue that has been caught, by triggering the issue resolution procedure spanning different DOs and ensembles.

The AI Planning module sustains the local adaptation of DOs, by supporting the refinement of abstract activities. It is in charge of managing the refinement procedure as an AI planning problem (Planner), providing the (composition of) fragments to be injected (Composer).