Ismael Bouassida Rodriguez

Jerome Lacouture
email: jlacoutu@laas.fr

Khalil Drira
email: khalil@laas.fr

Self-Adaptive Communication for Collaborative Mobile Entities in ERCMS

Keywords: Self-Adaptation, Communication, Collaboration

Adaptation of communication is required for maintaining the connectivity and the quality of communication in group-wide collaborative activities. This becomes challenging to handle when considering mobile entities in a wireless environment, requiring responsiveness and availability of the communication system. We address these challenges in the context of the ROSACE project where mobile ground and flying robots have to collaborate with each other and with remote human and artificial actors to save and rescue in case of disasters such as forest fires. This paper aims to expose a communication component architecture allowing to manage a cooperative adaptation which is aware of the activity and resource context into pervasive environment. This allows to provide the appropriate adaptation of the activity in response to evolutions of the activity requirements and the changes in relation with the communication resource constraints. In this paper, we present a simulation of a ROSACE use case. The results show how ROSACE entities collaborate to maintain the connectivity and to enhance the quality of communications.

Introduction

The ROSACE ("Robots and Embedded Self-adaptive communicating Systems") project aims at studying and developing means to design, specify, implement and deploy a set of mobile autonomous communicating and cooperating robots and software entities with well-established properties, particularly in terms of safety, self-healability, ability to achieve a set of missions and self-adaptation in a dynamic environment. A typical case study considers the context of mobile entities cooperating, into a pervasive environment, in critical operation for crisis management (i.e. to put out fires in a dynamic environment), dealing with heterogeneous and varying ubiquitous communication resources. In this context, communication is essential to achieve the mission objectives since it allows the exchange of information among participants activity. The dynamicity of the environment and the communication resources deployment affect communication integrity. The need to adapt communications is one of the main challenges of the ROSACE project. The communication system is designed as an organisation of autonomous entities which are in charge of managing the communication resources available in the mission in order to provide communication services with the best QoS to actors participating in the operating scenario.

Specific goals of the ROSACE communication system are:

1. to set up a local network to provide permanent connectivity among ROSACE actors;

2. to manage communication resources to guarantee a permanent connectivity among mission participants;

3. to provide best-adapted quality of service (QoS) according to communication goals and available resources (performance and consistency with activity requirements). For instance, communication priorities have to be taken into account depending on actor's role or the kind of exchanged data.

To achieve the previous goals, adaptation will require to manage the different communication layers (transport and middleware) taking into account the priorities of actors (possibly identified by their roles) and the priorities of the exchanged data. Adaptation should also proceed to modify the behaviour of the involved communicating entities, for example for serving as a communication relay, or more generally for serving to maintain the QoS. This can be achieved by activating predefined functions, acquiring new functions, or delegating to external dynamically discovered services. Managing adaptation calls for the need of monitoring crisis management activities of communication system, and monitoring the supported activity in order to handle the evolution of these requirements. It also requires cooperation among monitoring layers by receiving change notifications and by sending alarms when adaptation is not possible. This paper aims to present the challenge and the solutions for building adaptive communication components in the context of ERCMS (Emergency Response and Crisis Management Systems). Adaptive Communication entities are embedded software components deployed on mobile robots and other communicating devices. They are responsible for maintaining connectivity and quality of communication in group-wide collaborative activities, taking into account mission objectives.

The paper is organized as follow. Section 2 describes the ROSACE project and the case study related to communication adaptation. Section 3 gives an overview of existing communication adaptation techniques and works around autonomic computing. Section 4, we detail the architecture of a node communication manager component providing communication management and adaptation. Then, in section 5, we present how connectivity and QoS preservation is managed thanks to the node communication managers. After than, in section 6, we show simulation results that highlight benefits of our approach. Finally, we conclude.

2 Case study from the ROSACE project Within the context of the ROSACE project, we define a scenario to enable communication adaptation. The scenario involves various types of mobile actors that carry different types of communication devices such as ground and aerial communicating robots and human actors carrying mobile communicating devices in a wireless communication context. We distinguish human actors that may be professional actors with professional and specific communication devices or occasional actors that carry a mobile device (e.g. PDAs, Phones). We distinguish also, robot actors like planes, helicopters (Autonomous Aerial Vehicle -AAV) and ground robots (Autonomous Ground Vehicle -AGV).

The figure 1 gives an idea of the network organization between the different entities of a ROSACE scenario. Different actors (robots, firemen,...) with different roles (coordinator, investigator,...) are communicating using different types of communication (WiFi, Bluetooth,...) to purchase different goals (fight fire, rescue victims). In this context, the communication objectives are to adapt communication to maintain the connectivity and to propose the best QoS solutions. A main constraint is that, the communication system must deal with expected or unexpected evolution of actors needs and also it has to react to the changes due to device/network constraints.

ROSACE-like activities are based on information exchange between mobile participants collaborating to achieve a common mission. We define three generic roles: the supervisor of the mission, coordinators, and field investigators. Each participant is associated with an identifier, a role and the devices he uses. Each participant performs different functions:

1. The supervisor's functions include monitoring and authorizing/managing actions to be done by coordinators and investigators. The supervisor is the entity which supervises the whole mission. The supervisor waits for data from his coordinators who synthesize the current situation of the mission. The supervisor has permanent energy resources and high communication and CPU Capabilities;

2. Coordinators which are attached to the supervisor, have to manage an evolving group of investigators during the mission and to assign tasks to each one of them. The coordinator has also to collect, interpret, summarize and diffuse information from and towards investigators. The coordinator has high software and hardware capabilities.

3. The investigator's functions include exploring the operational field, observing, analyzing, and reporting about the situation. Investigators also act for helping, rescuing and repairing.

To support groupware activities, network-oriented services should be dynamically activated in response to implicit or explicit requests. These services should provide ubiquitous access to peers and they shloud be technology transparent either wired or wireless. They should take into account different time-varying requirements depending on the targeted activity, users' mobility, exchanged

Use cases

In ROSACE, we distinguish two main execution steps during a mission: the "Exploration step" (for the localization and the identification of the crisis situation) and the "Action step" (after the event identification). The following scenarios show possible situations where communications can actuate a mission adaptation with different adapted actions. These scenarios include unexpected connectivity discovery (case 1 and 2), expected future loss of connectivity (case 3), loss of connectivity detection (case 4), and a general overview on the management of priorities (case 5). Depending on the case, reactive or pro-active adaptations are considered. Considering the ROSACE action step, firemen, AAV and AGV are deployed and they are achieving their assigned goals.

Use case 1 -Communication device fortuitous discovery

An injured unconscious person equipped with a PDA, a smartphone or such a mobile device (not a device integrating a ROSACE Communication Component (CC)) with activated Bluetooth and/or Wifi interfaces (for instance via his mobile phone) is isolated in a barn/a building near the fire area, or in a trench and so on. Thereof a visual localization appears difficult and this person could escape to visual detection means. A ROSACE actor (i.e. a fireman or a AGV) achieving its goals is getting around the barn or the trench. With an autonomous and transparent way, the ROSACE device of this actor discovers a close unexpected device without disturbing mission performing. The ROSACE global system has to guarantee a localization service of injured persons or humans in danger. As a consequence, following the detection of a new connectivity by a ROSACE actor, the CC of this actor will communicate a notification message to broadcast this event to the control center. Later, the control center will decide to give the responsibility of an observation mission to confirm or not, or to assess, the presence of an injury. The continuation is a "target detection" scenario.

Use Case 2 -ROSACE communication device fortuitous discovery

The same scenario is applicable when the discovered entity is an active communication device carried by a ROSACE actor. This may happen when a new actor joins the group or when a disconnected actor is again in the scope of the communication signal. This situation may occur for example when a fireman has fallen or he is isolated in a building. The group composed of the interconnected ROSACE actors has lost the connectivity with this isolated actor.

Then, an entity of another group (e.g. an AGV) is getting around the isolated actor. The ROSACE system has to preserve the safety/integrity of the communication of its actors. As a consequence a similar sequence of actions (see case 1) could be planned. The result is the discovery of a "lost" and "isolated" ROSACE entity and an analysis starts to decide what are possible actions.

Use case 3 -Communication quality preservation/improvement

During the exploration step, a ROSACE group of entities is moving. To maintain the mission, a main goal is to preserve communication within ROSACE entity groups. We assume that a mobile communication entity is equipped with a wifi hotspot and a network is deployed around this hotspot. Another possibility is that a group of AGV (may be in parallel of a wifi infrastructure with hotspots) has built an ad hoc network via wifi interfaces (this network is potentially dedicated to a neighbourhood connectivity supervising). (In either case, each member can locally maintain, periodically, a list of reachable devices, associating to each detected device a level of connectivity quality).

In both cases, each entity could detect connectivity quality deterioration between connection interfaces. When a limit threshold value is crossed, a notification message is provided and sent to the control center and also sent to the internal decision making component of the entity. A possible consequence, independent of the message destination localization, is the suggestion to move the entity to preserve communication before a loss of connectivity.

Use Case 4 -Connectivity loss

Alike to the situation of the case 3, a CC detects a connectivity loss with another ROSACE entity (e.g. a robot moves away from the zone where other robots are deployed according to mission requirements). Thus, each of its previous neighbours can notify the network manager entity. Verification steps can be performed by the network manager, sending requests to previous neighbours to find communication relays or testing direct communication with the lost entity, and also locally by previous neighbours, testing other communication interfaces: Bluetooth, infrared, broadcast message for discovery. If the need arises, drones can be allocated to localize the isolated entity, starting the discovery from the last known GPS coordinates.

Use Case 5 -Communication priorities

A complementary scenario deals with the management of priorities. When a critical situation, a fire or an injured person is detected by a fireman or a robot, a relevant adaptation for communications is to give priorities to communication messages of this actor. Priorities will be in relation with the type of message, giving priority to cooperation messages, or the role of participants, giving priority to message from the supervisor to coordinators and from coordinator to investigators.

A communication component architecture

The presented scenarios show different goals we purchase concerning the management of communications in ROSACE-like environment. They illustrate different facets of communication adaptation that we have to take into account. Use cases 1 and 2 show that we must be able to adapt communications, exploiting them, in relation with mission objectives evolution (for instance, with communication devices discovery). Use cases 3 and 4 highlight the interest to develop on each node (each ROSACE entity) a way to manage connectivity and quality of communication. Finally, the use case 5 shows how priorities can be a first solution of connectivity communication management.

In previews works [START_REF] Rodriguez | Semantic driven self-adaptation of communications applied to ercms[END_REF], we have presented a semantic modeling approach to support priorities management and, more generally, to support mobile communicating systems. This first contribution, based on the design of ontologies, SWRL rules and adaptation actions, makes the adaptation aware of the evolving requirements of the activity being supported. In this paper, we present a communication component architecture, using this first contributions. We focus on the description of this adaptive architecture to highlight how adaptation is managed on each node of the network.

Related work

In this section, we present our reflections about adapting communication acting on the different communication layers (focusing on the transport and the middleware layers) and proposing an architecture supporting an adaptive mission-aware management. On the usefulness of adaptation, M. Satyanarayanan said in [START_REF] Satyanarayanan | Pervasive computing: Vision and challenges[END_REF] "adaptability is necessary when there is a significant disparity between supply and demand of a resource." Adaptation is the operation to make changes to a program or an information system to maintain its functionalities and, if possible, to improve its performance in a certain execution environment. In the area of ubiquitous computing and context-awareness, adaptation is extended by the concept of adaptability that characterizes a system capability to change its behavior to improve its performance or to continue its role in different environments.

Goals

After developing an information system, many reasons can lead to adapt it. The reasons for this adaptation can be for corrective, evolutional or perfective purposes [START_REF] Ketfi | Adaptation dynamique, concepts et experimentations[END_REF]. ROSACE adresses each of these reasons.

Corrective adaptation

In some cases, we can notice that the application does not behave properly or as expected. The corrective adaptation is a solution to identify the application module that causes the problem and to replace it by a new correct module. This new module provides the same functionality as the former.

Evolutional adaptation

When developing an application, some features are not taken into account. With the changing needs of the user, the application must be extended with new features. This extension can be accomplished by adding one or more modules to provide new features or modifying existing modules to enrich their functionality while keeping the same application architecture.

Perfective adaptation

The objective of this kind of adaptation is to improve application performance. For example, we can have a module that receives a lot of requests and fails to meet them. To avoid system performance degradation, we can duplicate this module to share the requests with the existing one.

Classification

The adaptation solutions suggested in the literature can be classified as follow.

Design vs run-Time

Two different adaptability views may be distinguished: the design time adaptability Dimka Karastoyanova (2004); [START_REF] Fahmy | Using graph rewriting to specify software architectural transformations[END_REF]; [START_REF] Ermel | Visual design of software architecture and evolution based on graph transformation[END_REF] and the run time adaptability [START_REF] Chang | Automatic configuration and run-time adaptation of distributed applications[END_REF]; [START_REF] Bade | Carsa -an architecture for the development of context adaptive retrieval systems[END_REF].

For the first view, we can find support tools that handles the application development cycle and optimizes the resources for example. For the run time adaptability [START_REF] Friday | Developing adaptive applications: The most experience[END_REF] presents several adaptation techniques among which use proxy services, change model of interaction and reorganize application structure.

Local vs Distributed

Adaptation may have a local or a distributed scope. Adaptive components can be deployed on a single machine or distributed on several machines. In the first case, the adaptation is local and only local changes are performed. In the second case, it is distributed and synchronization problems between peer adaptive entities have to be managed [START_REF] Bridges | Supporting coordinated adaption in networked systems[END_REF].

Behavioral vs architectural

The adaptation solutions suggested in the literature distinguish behavioral and architectural aspects. The adaptation is behavioral (or algorithmic) when the behavior of the adaptive service can be modified, without modifying its structure. Standard protocols such as TCP and specific protocols such as [START_REF] Wu | Streaming video over the internet: approaches and directions[END_REF]; Özgür B. [START_REF] Özgür | Atl: an adaptive transport layer suite for next-generation wireless internet[END_REF] provide behavior-based adaptation mechanisms. Behavioral adaptation is easy to implement but limits the adaptability properties.

The adaptation is architectural when the service composition can be modified IEEE (2000); [START_REF] Garlan | Introduction to the special issue on software architecture[END_REF]; [START_REF] Ellis | Toward a recommended practice for architectural description[END_REF] dynamically. In self-adaptive applications components are created and connected, or removed and disconnected during execution. The architectural changes respond to constraints related to the execution context involving, for example, variations of communication networks and processing resources. They may also respond to requirement evolution in the supported activities involving, for example, mobility of users and cooperation structure modification.

Objects of adaptation

Adaptation approaches target many levels of information systems: User interfaces, Content, Services, Middleware and Transport.

User interface adaptation

User interface adaptation consists in producing Human-Computer means that can be deployed and used on different types of terminals and which meet the user's preferences. Major existing work in user interface adaptation is based on models that describe the different aspects of the interaction between humans and machines. These models are implemented in different XML or UML languages like UMLi Pinheiro da [START_REF] Pinheiro Da Silva | UMLi: The unified modeling language for interactive applications[END_REF] and XIML [START_REF] Puerta | Ximl: a common representation for interaction data[END_REF]. These models are used to produce the adequate user interface code corresponding to the given XML or UML description. In the existing user interface adaptations, we distinguish two techniques: User Interface transformations and User Interface generation. In the first technique, the adaptation process starts from a description language which is very close to the user interface code that must be generated. This solution was adopted by [29] to produce adapted Web pages to different terminals starting from an XML description. In this kind of adaptation, style sheets (like XSLT) are used to specify replacement rules of XML tags by scripts that can be directly used by the target device. The second approach consists in generating user interfaces code starting from a high level description which is completely independent from the target programming language of the user interface. SEFAGI [START_REF] Chaari | Génération et adaptation automatiques des interfaces utilisateurs pour des environnements multiterminaux projet sefagi (simple environment for adaptable graphical interfaces)[END_REF] is an example of platforms using the generation technique to ensure user interface adaptation.

Content adaptation

Since the appearance of pervasive systems, the adaptation of multimedia content has been the subject of considerable research. Several techniques for adapting the delivered data to the user have been proposed. These techniques are based on textual transformations [START_REF] Nagao | Semantic annotation and transcoding: Making web content more accessible[END_REF], [START_REF] Housel | Webexpress: a system for optimizing web browsing in a wireless environment[END_REF], image transcoding [START_REF] Wee | Secure scalable streaming and secure transcoding with jpeg-2000[END_REF], or processing video and audio. One of the major issues in content adaptation is where the decision-making and transformations are made. In the literature, three general approaches have been proposed according to the location of adaptation processing between the source that hosts the content and destination that requests it:

1. on the content provider side; 2. on the requester side; 3. at an intermediary (proxy) between the data source and the client.

The content provider-side solutions have some drawbacks. Indeed, the changes made on the content induce a calculation load and consequent resource consumption on the server. However, this approach is very suitable for situations with low variability and low adaptation frequency regarding the simplicity of its implementation. But it is not reliable for cases where the adaptation is triggered frequently.

The content requester-side approach is suitable when the transmission characteristics are less critical than the display limits of the user device [START_REF] Nandagopal | Service differentiation through end-to-end rate control in low bandwidth wireless packet networks[END_REF]. However, the usual complexity of adaptation processing hampers the wide adoption of this approach [START_REF] Perkis | Universal multimedia access from wired and wireless systems[END_REF]. Indeed, the client's terminal has generally very limited computing capacity, power and storage.

For the proxy solution, the flexibility of positioning the adaptation mechanisms on the best content distribution point is a major advantage compared to the other approaches (provider and content sides). However, the proxy must be a trusted party by the provider and the requester of the content. In addition, the third party may charge for the service it provides and the resources it employs to perform the adaptation for the receiver. Therefore, accounting mechanisms should be incorporated in the proxy solution in order to keep track of the amount of resources utilized and the usage of the data.

Service adaptation

Service-Oriented Architecture (SOA) paradigm is based on dynamically publishing and discovering services. This kind of architectures provides the possibilities to dynamically compose services for adapting applications to contexts. Service descriptions are published, via the registry, by service providers and dynamically discovered by service requesters. There are various implementation technologies like COM/ DCOM (Component Object Model) Rogerson (1997); [START_REF] Grimes | Professional Dcom Programming[END_REF] of Microsoft, the EJB (Enterprise Java Beans) [START_REF] Matena | Applying Enterprise Javabeans: Component-Based Development for the J2ee Platform[END_REF]; Thomas (1998) of Sun Microsystems or CCM (CORBA Component Model) OMG (1999) of OMG (Object Management Group). We can also consider JXTA [START_REF] Sun | Cme: a middleware architecture for network-aware adaptive applications[END_REF] the peer to peer framework or .NET Microsoft (2001) of Microsoft.

Middleware adaptation

Other frameworks are proposed to provide adaptability at the middleware level. In [START_REF] Nasser | Adaptive bandwidth framework for provisioning connection-level qos for nextgeneration wireless cellular networks[END_REF], an adaptive framework for supporting multiple classes of multimedia services with different QoS requirements in wireless cellular networks is proposed. [START_REF] Sun | Cme: a middleware architecture for network-aware adaptive applications[END_REF] proposes CME, a middleware architecture for service adaptation based on network awareness. CME is structured as the software platform both to provide network awareness to applications and to manage network resources in an adaptive fashion.

Transport adaptation

At the transport level, [START_REF] Exposito | FPTP: the XQoS aware and fully programmable transport protocol[END_REF] provide frameworks for designing Transport protocols whose internal structure can be modified according to the application requirements and network constraints. Adaptation actions correspond to the replacement of a processing module or micro-protocol by another following a plug and play approach.

Model based adaptation approaches

There are many relevant contributions concerning system architecture adaptation. This kind of approaches uses model-based strategies to apply the necessary transformations on the systems architecture to adapt it to environment and requirement changes. These strategies define or reuse models describing the system software architectures. These models are also known as ADLs (Architecture description languages). We distinguish between there general ADL types: formal ADLs like graph grammars [START_REF] Hirsch | Graph grammars and constraint solving for software architecture styles[END_REF] and Petri nets [START_REF] Murata | Petri nets: Properties, analysis and applications[END_REF], semantic ADLs using ontologies [START_REF] Zhou | Applying ontology in architecture-based selfmanagement applications[END_REF] and technical ADLs using XML deployment languages in general [START_REF] Dashofy | An infrastructure for the rapid development of xml-based architecture description languages[END_REF]. The technical ADLs can be proprietary or implementing the formal and the semantic architecture description models. These ADLs are used to guarantee the architecture evolving and correctness during the different predictable and unpredictable changes in the systems environment. The necessary actions to achieve such adaptations are specified in rules according to the application runtime context. [START_REF] Chaari | Adaptation in Context-Aware Pervasive Information Systems: The SECAS Project[END_REF] is an example of these approaches defining a complete model based architecture adaptation at the Service, content and user interface levels. [START_REF] Chassot | Towards autonomous management of qos through model-driven adaptability in communication-centric systems[END_REF] presents another model based method using graph grammars to adapt cooperative information systems to situation changes at the communication level.

Autonomic Computing

Managing autonomic systems requires to consider abstraction levels. A coordination is needed within and between these abstraction levels. Distinguishing these abstraction levels allows designers and developers to master specification and implementation of adaptation rules. The autonomic concept and systems suggested in the literature are defined in various ways. We target in our study the solutions given within and between differents levels.

Basic concepts of autonomic computing

In this section we present works that focus at the need of autonomic computing and the first concepts are introduced. They focus and detail the autonomic control loop.

For IBM in [START_REF] Kephart | The vision of autonomic computing[END_REF]Autonomic computing systems are those systems that automatically manage themselves by carrying out tasks that have been traditionally performed by computer specialists. The selfmanagement tasks are defined. Self-optimization is the ability of the system to optimize the use of resources. Selfhealing is the ability of the system to detect faulty behaviour and self-repair. Self-configuration is the capacity of the system to change its structure and behavior. And self-protection is the ability of the system to detect intrusions, policy violation, etc. and recover from them.

In IBM ( 2006) the internal functional architecture of an Autonomic Element is shown in this paper. This architecture is composed of a number of functional modules that enable the expected autonomic behavior through a set of autonomic operations. The autonomic operations are achieved using a self-adjusting control loop. Inputs to the control loop consist of various status signals from the system or component being controlled, along with policydriven management rules that orchestrate the behavior of the system or component. Outputs are commands to the system or component to adjust its operation, along with messages to other autonomic elements.

In [START_REF] Dobson | A survey of autonomic communications[END_REF], the authors present a survey of the state of research in autonomic communications and present the autonomic control loop for network communication. They address the five interlinked perspectives of the design and analysis of decentralized algorithms; the modelling, handling and use of context, novel and extended programming approaches; issues and approaches for addressing security and trust; and systems evaluation and testing. They match the challenges such as interaction with stranger, Information reflection and collection, lack of centralized goals and control, meaningful adaptation, cooperative behavior in the face of competition, heterogeneous services and semantics, against the cross-cutting issues and show the technical ideas emerging from each issue when addressing each challenge.

Networks level

In this section we present some works that consider the network point of view of autonomic computing. [START_REF] Van Der Meer | Emerging principles of autonomic network management[END_REF] explains Autonomic Network definition in more detail, links it to the foundational principles of architecture for Autonomic Network Management, and provides guidance on how to develop specifications and best practices for the building of Autonomic Communication Systems. They define a required terminology necessary to support the realization of an Autonomic Communications Framework, and also a flexible framework that can be used as the foundation of autonomic network management. Finally, they specify how this framework can be used to build Autonomic Communications Environments. Four research areas are covered that, in combination, define the foundations of autonomic network management: Modelling and Knowledge Engineering for Autonomic Network Management; Automating Network Configuration via Model-Centred Policy Analysis and Deployment; Network Algorithms and Processes; Architecture and Methodology for Autonomic Network Management. [START_REF] Agoulmine | Challenges for autonomic network management[END_REF] gives an overview of the different architectures that support the design, implementation and deployment of autonomic systems. Authors give the motivation behind the emergence of autonomic, self-managed systems and the required features of such architectures. Then, they propose different architectures. They discuss the complexity related to the autonomic information modelling and the autonomic behavior. They present the potential of bio-inspired techniques and compare it with autonomic concepts. [START_REF] Mullany | Self-deployment, self-configuration: Critical future paradigms for wireless access networks[END_REF] examines the trends in nextgeneration wireless access networks that will lead to the increasing significance of the costs associated with the deployment and configuration of such networks. The authors propose, the concept of a self-deploying, self-configuring radio access network to resolve these issues. They propose algorithms from economic theory, ecology/population growth models, or cellular automata. An example, taken from the field of cellular automata for a radio network capable of self-adaptation to achieve universal coverage in a simplified environment was examined.

In [START_REF] Xiao | Qos-aware service composition and adaptation in autonomic communication[END_REF], the authors present a mechanism for QoS-aware service composition and adaptation of end-to-end network service for autonomic communica-tion. They introduce a service provisioning framework based on the autonomic communication principle, covering a number of essential functions: domain discovery, domain reacheability, composition, cross-domain contracting, intra-domain provisioning, domain-wide monitoring, and adaptation. Through domain graph abstraction, they reduce the domain composition and adaptation problem to the classic -multiconstrained optimal path problem. They develop a set of new algorithms for QoS-aware service composition and adaptation. Their composition algorithm finds a series of consecutive domains spanning end-to-end and select appropriate service class in each domain such that the overall QoS requirements are satisfied. The algorithm also minimizes the overall cost of the path. As the network condition changes over time or as the user roams across domains, the adaptation algorithm ensures the QoS requirements of the communication path is respected as long as it is feasible to do so, while minimizing the cost of such adjustments. Together, these algorithms are designed to support self-configuration, self-optimization, and self-adaptation of network communication services. They address the service provisioning problem at the domain level, the algorithms can function over heterogeneous intradomain provisioning mechanisms, and more importantly, provide hard end-to-end QoS guarantees over "soft" intradomain QoS schemes.

Application level with Agents

In this section we focus in some works that consider a Multi-Agent approach for autonomic systems. [START_REF] Locatelli | Awareness in collaborative ubiquitous environments: The multilayered multi-agent situated system approach[END_REF] describes a Multi-Agent approach to the modelling and design of Collaborative Ubiquitous Environments, that are environments that support collaboration among persons in a context of ubiquitous computing. In particular, the paper shows how research in the topic of Multi-Agent Systems environment has provided both modelling abstractions and concrete computational supports for the analysis, design and engineering of Collaborative Ubiquitous Environments. In particular, the Multilayered Multi-Agent Situated System model was applied to represent and to manage several types of awareness information (both physical and logical contextual information), which is an essential part of a Collaborative Ubiquitous Environment.

This work differs from other existing proposals that employ agents and agent-based infrastructures simply as a middleware for the design and implementation of pervasive computing systems. The authors present also a selection of the available platforms developed in this context and discuss their suitability to support the development of Collaborative Ubiquitous Environments. [START_REF] Johnson | The multilevel hypernetwork dynamics of complex systems of robot soccer agents[END_REF] begins by discussing some of the general issues of complex systems and explains why the agent-based approach is attractive. The article investigates the application of multilevel hypernetworks in team robotics as an example of a complex interaction-based system. The authors show how hypernetworks can represent multilevel relational dynamics by the in-depth analysis of a robot soccer simulation game. They have sketched a mathematical formalism for representing the relational structure between agents.

Frameworks and architectural proposals

In [START_REF] Liu | Accord: a programming framework for autonomic applications[END_REF], the authors present the Accord programming framework that extends existing programming models/frameworks to support the development of autonomic applications in wide area distributed environments. The framework builds on the separation of the composition aspects (e.g., organization, interaction, and coordination) of elements from their computational behaviours that underlies the component-and service-based paradigm, and extends it to enable the computational behaviors of objects/components/services as well as their organizations, interactions, and coordination to be managed at runtime using high level rules. The operation of the proposed framework is illustrated using a forest fire management application.

In Yechiam [START_REF] Yechiam Yemini | Nestor: An architecture for network selfmanagement and organization[END_REF], the authors present The NESTOR system. The NESTOR system addresses the needs of network management automation, the complexity of management of Large networks and of minimizing the management of small home networks due to limited resources. The NESTOR system combines several techniques from object modelling, constraint systems, active databases, and distributed systems. In the NESTOR system, managers operate on a unified object-relationship model of the network using a rich set of operations that support rollback and/or recovery of operational configuration states. Declarative constraints prevent known configuration inconsistencies, and in conjunction with policy scripts may automatically propagate changes to maintain consistency. Protocol proxies are used to provide much of this functionality with little or no changes in the network clients. A protocol for replication and distribution of the directory assures availability and operational efficiency. Other works try to analyse Autonomic Computing Systems. [START_REF] Litoiu | A performance analysis method for autonomic computing systems[END_REF] investigates performance analysis techniques used by an autonomic manager. It looks at the complexity of the workloads and presents algorithms for computing the bounds of performance metrics for distributed systems under asymptotic and nonasymptotic conditions, with saturated and nonsaturated resources. The techniques used are hybrid, making use of performance evaluation and linear and nonlinear programming models. The authors treat autonomic transactional distributed systems. The system is modelled with a Queuing Network Model.

Mobile networked systems for the support of group-wide activities have to provide dynamic adaptability for runtime and design-time changes. Such changes are induced by evolving requirements of the supported activities and by evolving resource constraints.

Designing and implementing self-adaptive communicating systems to support such emerging activities is complex.

Mastering this complexity may be achieved by adopting model-based design approaches associated with automated management techniques for dynamic architectural and behavioral adaptability management.

The exposed works allow clarifying the different problems related to self-adaptability. The proposed solutions have different features related to the targeted goals (e.g. QoS, security...), the considered layers (e.g. Application layer, Transport layer...), the adaptation actions (e.g. rate control, congestion control...), the adaptation properties (e.g. architectural, behavioral...), and the way to manage the adaptation and its autonomy.

To face the different kinds of requirements and constraints evolving, behavioral and architectural adaptability is required at several levels simultaneously. This typical cross layering problematic requires managing coordination without which it can lead to performances way below the targeted ones.

For group communication-based cooperative activities, abstraction levels have to be identified. Adaptation at the highest levels should be guided by the evolving of the activity requirements. Adaptation at the lowest levels should be driven by the changes due to device/network constraints.

In previous works [START_REF] Rodriguez | Semantic driven self-adaptation of communications applied to ercms[END_REF], we provide semantic tools (ontologies, SWRL rules, ...) to allow to manage adaptation reacting to needs, priorities and environment changes. The next step, presented in this paper, is to specify and detail the architecture of our communication component manager. The next section details this component which is based on the use of semantic tools.

Node communication manager architecture

To support and manage adaptation of communication, following directions presented in the section above and taking into account priorities, we specify a communication component (NCM: Node Communication Manager) encapsulated in each ROSACE entity (ubiquitous device or robots).

Node Communication Manager components (NCM) are thought as high level computing components which encapsulate knowledge and skills about communication infrastructure, networking and transmission technologies. They offer their capabilities to the rest of entities as services which are provided through standard interfaces. In order to achieve service efficiency the NCM will have the following capabilities:

• Mission information awareness, NCM could have access to mission information such as participants, roles, priorities, location and other information which may be used for communication service provisioning;

• Contextual information awareness. This includes: a)

The internal context of the underlaying node containing where the NCM is located, and b) the environmental context, where are situated the rest of nodes and NCM's participating in service provisioning;

• Seamless Management of communication resources in hosting nodes to achieve adaptive communication needs. This includes: a) managing internal service APIs and related middleware to configure, set up, and monitoring communication services, b) assessing service quality according to mission needs, c) dynamic re-configuration and management of internal resources to satisfy communication service requirements;

• Cooperation with the rest of NCMs to achieve Organizational goals. This includes: a) achieving its own goals sharing common resources with other NCMs, b) managing internal resources to satisfy collaboration requests, c) interacting with other NCMs to exchange control information and data to guaranty end to end service provisioning and quality control.

NCMs are embedded in mobile robots and other telecommunication devices such as PDA's. They are expected to manage efficiently the overall communication resources in the hosting node where they are deployed. As service providers for other internal units they should report errors and exceptions to their internal client components. If possible, they suggest corrective actions to the control center or decision-making units. Moreover, at the implementation level, a NCM can be viewed as a Multi-Agent System where each internal component would be a role played by a software agent.

The NCM architecture we developed is presented in figure 2. This architecture is composed of a set of component : • The TransportProtocolStack components manage each protocol stack allowing the different types of communication (Wifi, Bluetooth, infrared or GSM). It generates status from the created links.

5 Connectivity and QoS preservation using NCM

In this section, we show how NCM could produce an efficient adaptation to preserve connectivity or to improve QoS. Our first experimentations refer to use cases presented in section 2. We have considered different situations with communication problems and we have experimented it throw a simulation.

In this paper, we present one of these situations to illustrate NCM benefits. The chosen scenario illustrates different aspect exposed in the presented use cases (connectivity preservation, communication quality improvement, ROSACE communication device fortuitous discovery). Therefore, we consider a group of four ROSACE robots (A ROSACE Robot is a robot equipped with an NCM). The figure 3 gives a summary of the sequence of events of the scenario.

• Step 0. Initially two ground robots (Robot Robot4 and Robot Robot6 (see figure 1) are communicating together. The communication flow between Robot4 and Robot6 is considered as important for their cooperation.

• Step 1. In relation with mission objectives (rescue), Robot6 has to move away. For instance, this step could be initiated if a robot receives a recommandation from the control center to find injured in an area near its position. The ComResourceManager of Robot6 and Robot4 detect a lost rate increase (a policy of adaptation report a problem (connectivity loss) when a threshold of adaptability is reached). A suggestion of adaptation is decided and sent by the de-cisionModelManager of each robot ("move Coordina-tor2 to maintain the connectivity").

• Step 2. We consider that Robot4 can't move from his position due to mission constraints. To maintain the communication between Robot4 and Robot6, Coordi-nator2 has to move near Robot6 (Step 3). For the simulation, we consider that Robot4 sends to Robot6 a video flow continuously using MPEG2 protocol. We consider X, a random variable that has a normal distribution with parameters µ and σ which characterizes the

Step 0

Step 1 R6 is moving away The metric observed to evaluate the connectivity and the quality of the existing flow is the number of lost packets (packet of data that never reaches its destination).

In figure 4, the number of lost packets increases slowly in Step 0. After a minute on the simulation start, Step 1 begins and Robot6 moves to find an injured person in an area near its position. The number of lost packets increases rapidly and reaches the threshold. The process of adaptation is triggered here (see the point A in figure 4) and Coordinator2 moves to avoid connectivity lost. The Step 2 starts, and the number of lost packets decreases in the first minutes of this step. But the number of lost packets still beyond the comfort threshold enough time (1 minute for our simulation) to trigger an adaptation action. Robot3 is used as a relay for communication. Robot3 comes near to Coordinator2 and Robot6. This action is required to enhance the quality of communication. The Step 3 starts and the number of lost packets decreases. Robot6 is arrived at the required position, Coordinator2 and Robot3 maintain the communication between Robot4 and Robot6. It stills a lost of packets but in acceptable level.

Without the adaptation of communication by NCM, many communication concerns still unresolve (connectivity loss (Step 1) or unusable connections (Step 2)). These first results stimulate the development and the deployment of NCM on each node of the network. Using NCMs allows, thanks to a permanent observation of communication activity (in the simulation the observation of the number of lost packets) and the specification of adaptation policy, to adapt communications (NCM allows different types of communication adaptation: switching communication mode, changing quality of communcation services or physical adaptation actions like "moving the robot"). A sim-ulator is currently developed in the scope of the Rosace project to test more complex scenarios with more collaborative and realistic situations.

conclusion

In this paper, we have presented an adaptive communication issue in the context of the ROSACE project where mobile actors collaborate, into a pervasive environment, to manage emergency situations such as those occurring during disasters of forest fires. We have identified and discussed the main scenarios where adapting communication is needed for the achievement of the actors mission objectives. We have developed a communication component (NCM) to manage communication adaptation in relation with mission constraints evolution and unpredictable events. This component is distributed in each node of the Rosace network (in each robot, human devices (PDA),...). We have conducted a simulation of a ROSACE use case. This simulation shows the manner that ROSACE entities collaborate to maintain connectivity and enhance quality of communications. In the future, we plan to extend the simulation and involve more entities. The interaction between coordinators and the control center needs to be simulated too. In our work, we consider several connections (Wifi, Bluetooth, etc.). Besides, it will be important to study the cost of using different technology in terms of efficiency.

Figure 3 :

 3 Figure 3: Connectivity and QoS preservation scenario

Figure 4 :

 4 Figure 4: Simulation results using NCM


Amal Gassara
email: amal.gassara@redcad.org

Ismael Bouassida Rodriguez

Mohamed Jmaiel
email: mohamed.jmaiel@enis.rnu.tn

A multi-scale modeling approach for software architecture deployment

Keywords: Deployment architecture, Correctness, Multi-scale modeling, Bigraphs, BRS

For large component-based applications, identifying a valid deployment architecture has emerged as a major challenge. Actually, this deployment architecture (i.e, allocation of software components to its hardware hosts) should satisfy various constraints related to the software components and the target environment such as the hierarchical description of components, their connections and the resource constraints. The numerous constraints make hard to construct manually the correct deployment architecture. In this work, we propose a formal method based on a formal language called BRS (Bigraphical Reactive System) in order to guarantee the correctness of the deployment architecture. Furthermore, in order to support its automatic construction, our proposed method follows a multi-scale modeling. In fact, the designer starts by modeling the first scale architecture which is refined automatically by successively adding smaller scale components until obtaining the deployment architecture at the last scale. This refinement is ensured by applying a set of rules. In this paper, we address communicating systems as a study domain.

INTRODUCTION

With the continuous change of computer systems, software development is more and more complex and brings new challenges. Software deployment is considered one of challenging tasks. It represents a sequence of related activities for placing a developed application into its target environment and making the application ready for use. For large distributed systems, finding a correct deployment architecture can be a challenging issue. Actually, a correct deployment architecture should satisfies various constraints related to both software components and target environment such as the hierarchical description of components, their connections and the resource constraints. These constraints make hard and might be impossible to find manually the correct architecture. Instead, several correct deployment architectures can be found. So, it is necessary to choose the efficient one to be deployed. The difficulty of this task motivate us to look for a solution to automate the construction of the correct and the efficient deployment architecture. So, in this paper, we focus on the construction of correct deployment architectures (i.e., that respect structural constraints like the hierarchy of components and their connections). Then, in our ongoing work, the efficient architecture is selected according to resource constraints. In the literature, there are several research activities dealing with software deployment. But most of them are based on informal model and lack a solid mathematic foundation to ensure the correctness of deployment architecture. They have focused on satisfying only the resource constraints. Whereas, in our work, we use BRS (Bigraphical Reactive System) as a formal foundation. Moreover, our approach is based on a multi-scale modeling that helps to automate the construction of correct deployment architectures. Actually, in order to generate deployment architectures, we need to specify the software architecture model that describes the software components and their composition and the execution environment model that describes the target environment architecture on which application will be deployed. In fact, each model is represented as a set of scales, and each scale denotes a set of architectures represented as bigraphs. Following our approach, the designer starts by modeling the first scale architecture which is refined to give one or many architectures for the next scale. Then, these architectures are refined in turn to give the following scale architectures and so on until reaching the last scale. The transition between scales is ensured by applying specific rules defined as bigraphical reaction rules. After constructing the architectures of both software architecture model and execution environment model, we apply the relation between the two models in order to obtain deployment architectures.

The rest of this paper is organized as follows. In section 2, research activities dealing with software deployment are presented and in section 3, we present an overview of bigraphs. In section 4, we explain our bigraphical based approach for the deployment modeling. In section 5, we consider communicating systems as a study field. Then, we introduce in section 6 a case study called "Smart Home" to apply our approach and its simulation with the BPL Tool in section 7. Finally, section 8 concludes this paper and gives some directions for future work.

RELATED WORK

Various research studies have proposed methods to address the issues of software deployment. These methods include the use of OMG Deployment and Configuration (D&C) specification [START_REF] Object | Deployment and configuration of component-based distributed applications specification[END_REF]. we have identified some frameworks which have been developed on top on this specification like DAnCE [START_REF] Deng | Dance: A qos-enabled component deployment and configuration engine[END_REF], Dacar [START_REF] Dubus | Towards Model-Driven Validation of Autonomic Software Systems in Open Distributed Environments[END_REF] and Deployment Factory [START_REF] Hnetynka | A model-driven environment for component deployment[END_REF]. DAnCE is a QoS-enabled Component Deployment and Configuration Engine targeted for DRE systems. This framework deals only with CORBA Component Model. Whereas Deployment Factory is an unified environment for deploying component based applications. It proposes a generic component model which is an extension to the OMG D&C specification. These frameworks do not provide mechanisms for redeployment and dynamic reconfiguration. However, Dacar is a model-based framework for deploying autonomic software distributed systems. It is based on a control loop and Event-Condition-Action (ECA) rules. The main limitation of these research activities is the manual deployment planning. The designer should assign the software components to the hardware ones which is a hard task especially with large scale systems.

Other research activities have proposed architecture-based approaches using ADL (Architecture Description Language) [START_REF] Hoareau | Constraint-based deployment of distributed components in a dynamic network[END_REF][START_REF] Malek | An extensible framework for improving a distributed software system's deployment architecture[END_REF] and graphs [START_REF] Heydarnoori | Reliable deployment of component-based applications into distributed environments[END_REF][START_REF] Zhang | Deployment planning of component-based distributed applications using mathematical programming[END_REF][START_REF] Rodriguez | Multi-layer coordinated adaptation based on graph refinement for cooperative activities[END_REF]. Hoareau et al [START_REF] Hoareau | Constraint-based deployment of distributed components in a dynamic network[END_REF] present a support for deploying and executing an application built with hierarchical components. It presents an ADL extension for specifying a context-aware deployment. This deployment is performed in a propagative way and is driven by constraints put on the resources of the target hosts. The framework presented in the work of Malek et al [START_REF] Malek | An extensible framework for improving a distributed software system's deployment architecture[END_REF] aims at finding the most appropriate deployment architecture for a distributed software system with respect to multiple QoS dimensions. The framework supports formal modeling of the problem that provides a set of algorithms for finding the optimal deployment. Heydarnoori et al [START_REF] Heydarnoori | Reliable deployment of component-based applications into distributed environments[END_REF] propose a graph based deployment planning approach for maximizing the reliability of component-based applications. They demonstrate that this deployment problem corresponds to the multiway cut problem in graph theory. Also, the work of Zhang et al [START_REF] Zhang | Deployment planning of component-based distributed applications using mathematical programming[END_REF] defines a component graph to represent componentbased distributed applications and a tree network topology to describe the runtime environment. It defines the resource cost objective function and formulates component deployment optimization problem as mathematical programming problem.

Other research studies like [START_REF] Dearle | A framework for constraint-based deployment and autonomic management of distributed applications[END_REF][START_REF] Matougui | A middleware architecture for autonomic software deployment[END_REF] have proposed a dedicated language (Domain Specific Language) for deployment. Dearle and Kirby [START_REF] Dearle | A framework for constraint-based deployment and autonomic management of distributed applications[END_REF] propose a framework for autonomic management deployment and configuration of component-based distributed applications. An initial deployment goal is specified using Deladas (DEclarative LAnguage for Describing Autonomic Systems). A constraint solver is used to find a configuration that satisfies the goal, and the configuration is deployed automatically. If, during execution, the goal is no longer being met, a full restart of the deployment process is performed. Matougui et al [START_REF] Matougui | A middleware architecture for autonomic software deployment[END_REF] propose the j-ASD middleware that addresses the autonomic deployment of ubiquitous systems. This middleware provides a DSL specifying deployment constraints. This specification is compiled into a constraint satisfaction problem, which is resolved automatically by a constraint solver. The generated deployment plan is dynamically executed by a mobile agent system.

We can note that the research activities [START_REF] Hoareau | Constraint-based deployment of distributed components in a dynamic network[END_REF][START_REF] Malek | An extensible framework for improving a distributed software system's deployment architecture[END_REF][START_REF] Heydarnoori | Reliable deployment of component-based applications into distributed environments[END_REF][START_REF] Zhang | Deployment planning of component-based distributed applications using mathematical programming[END_REF][START_REF] Dearle | A framework for constraint-based deployment and autonomic management of distributed applications[END_REF][START_REF] Matougui | A middleware architecture for autonomic software deployment[END_REF] deal only with resource constraints during the construction of the deployment architecture. They do not take into account the respect of structural constraints to validate he deployment architecture. Whereas, in our work, we deal with both structural and resource constraints.

PRELIMINARIES 3.1 Bigraphs

Bigraphs [START_REF] Milner | Bigraphical reactive systems: basic theory[END_REF] formalise distributed systems by emphasizing both locality and connectivity. A bigraph consists principally of hyperedges and nodes which can be nested and have ports. Each hyperedge can connect many ports on different nodes. Each node in the bigraph is assigned a control. Controls indicate the node type and the node ports' number through the arity. We can use the notation "X-node", which means a node that has been assigned the control X.

Bigraphical Reactive System

A BRS (Bigraphical Reactive System) is a set of bigraphs and a set of reaction rules that may be applied to rewrite these bigraphs. Each reaction rule consists of two bigraphs: a Redex R and a Reactum R'. The application of the rule consists of identifying the image of R in a bigraph and replacing it by the corresponding R'.The graphical representation used above is handy for modeling, but unwieldy for reasoning. Fortunately, bigraphs have an associated term language [START_REF] Birkedal | Bigraphical models of context-aware 1 https://a2nets.erve.vtt.fi/ systems[END_REF].

THE PROPOSED APPROACH

In order to construct a deployment architecture, we need to describe the software architecture, the execution environment and the relation between them. Based on this issue, we propose an approach for deployment modeling of distributed systems which defines:

• Software architecture model: This model describes software components, their properties and their architecture (i.e, hierarchy of components and connections between them).

• Execution environment model: This model describes the runtime environment including physical nodes, hosts, devices, etc as well as their resource constraints and their architecture.

• Relation between the software architecture model and the execution environment model: To obtain a deployment architecture, we should define the relation between the two models to map software components on physical ones.

The key objective of our work is to automate the construction of a correct deployment architecture that respects the defined models. For this, we have proposed a formal method which is based on a formal language to guarantee the correctness of the deployment architecture. This formal language should be able to describe both software and physical components. It should emphasize both hierarchy and connectivity of components. It should also provides information on both static and dynamic aspect of the system since we intend to deal with autonomic systems in future work. We have noticed that BRS is the most appropriate language that supports these requirements. Furthermore, our formal method provides three steps to be followed:

-Step 1: Description In this step, the designer describes the necessary information like software and hardware components, their properties and their resource constraints. Each component is represented with Bigraph as a node type annotated with attributes to indicate properties or available resources. The designer describes also the structural constraints through conditions on the hierarchy and the connectivity of nodes.

-Step 2: Generation In this step, the generation of the deployment architecture is performed automatically following a multiscale modeling approach. In fact, for each model (i.e., environment execution model and software architecture model), a large scale is defined by the designer. Then, it is refined by successively adding smaller scale details until reaching the last scale. Hence, we obtain the set of possible deployment architectures by linking the two models.

The refinement process is performed by applying specific rules. Since we aim to facilitate the modeling task for the designer, we have proposed the concept of meta-rule to describe the transition between scales. Thus, the designer identifies the corresponding meta-rule which will be instantiated automatically according to the specification in order to have the necessary rules for scale transitions. With BRS, a meta-rule is a meta-reaction rule that contains nodes having a variable control (i.e., a variable can represent any control).

-Step 3: Selection In our ongoing work, a deployment architecture is selected from those generated in the previous step according to resource constraints. Hence, we obtain a deployment architecture that respects both structural and resource constraints.

MULTI-SCALE MODELING FOR COM-MUNICATING SYSTEMS

In our work, we have addressed communicating systems.

Since we aim to facilitate the modeling task to the designer, we have defined, for these systems, the scales of each model and we have defined the necessary meta-rules to be applied for the transitions between these scales and for the relation between the execution environment model and the software architecture model.

The execution environment model

This model is represented by the following scales and transitions (we use the notation "scale i" where i is the scale number):

-Scale i: such i ∈ [0, n]
where n corresponds to the depth of nesting in a bigraph. For i = 0, we obtain the first scale.

-Transition from scale i to scale i + 1: The transition to the scale i + 1 is obtained by applying a meta-reaction rule allowing to nest a node.The corresponding algebraic expression of this rule is:

Nest a node: X.d0 → X.(Y |d0)
This rule enables to nest a node. So, the transition between two scales leads to increment by 1 the depth of nesting. Therefore, this meta-rule can be applied several times in order to add many nodes residing in the same node.

-Scale i + 1:

such i ∈ ]0, n].
With i=n, we obtain the scale n that represents all physical entities and their composition (i.e, hierarchy). So, we reach this scale when there is no physical entities to add.

-Transition from scale n to scale n + 1: The transition to the scale n + 1 is characterized by defining the link graph. So, we add hyperedges that represent the communication between different devices of the application. This operation is defined by a closure /x • G (i.e., outer names x under a bigraph G is replaced by an edge). Hence, we link nodes belonging the same communication group (i.e., having the same outer name).

-Scale n + 1: This is the last scale of the execution environment model. It represents all the physical entities and their communication.

Relation between execution environment and software architecture models

We propose that the relation between the software architecture model and the execution environment model is a transition from scale n + 1 of the execution environment model to scale 0 of the software architecture model. The latter includes sender and receiver components. In fact, each communication group is ensured by a set of senders and receivers. We consider that communication is done in pull mode (i.e., response to a request). So, an entity belonging a communication group should contains a pair of sender and receiver.

To ensure this transition, we define the following meta-rule: Add a sender and a receiver:

Yx → Yx.(Sr.x|Rc.x)
We nest in each node having an outername x, a sender (Srnode) and a receiver (Rc-node), then we nest in both of them an x-node that mark their communication group.

The software architecture model

For communicating systems, the software architecture model includes the entities that take part in the communication like senders, receivers and communication middleware components. Hence, we have identified for this model the neces-sary components, three scales and transitions between them by defining corresponding meta-rules.

-Scale 0: represents sender and receiver components.

-Scale 1: provides the middleware components that ensure the communication between the application components.

Here, we use the Event-Based Communications (EBC) [START_REF] Meier | Taxonomy of distributed event-based programming systems[END_REF]. EBC is a communication model which provides three types of EBC entities: event producers (EP), event consumers (EC) and channel managers (CM). The EP and EC can be connected to CM, but they can not be directly interconnected. The EP can send data to the CM to which they are connected. The CM returns a copy of the received data to all the EC connected to it. This scale is obtained by nesting an EP-node in each sender, an EC-node in each receiver and a CM-node for each communication group in a node that belongs to this group.

-Transition from scale 0 to scale 1: This transition is performed by applying a set of meta-reaction rules defined by the algebraic expressions given below:

Add

CASE STUDY: SMART HOME

In order to apply our approach, we consider a case study named "Smart Home" denoted in the Figure 1. Each room in a smart home can be equipped with heterogeneous devices (sensors like thermometer, presence sensor, light sensor, etc and actuators like air conditioner, lamp, etc). These devices are connected to a home gateway that manages their communication to ensure an intelligent home control like lighting control and temperature control. Sensors record information such as rooms lighting, human presence, temperature, etc.

The home gateway receives these information and analyses them in order to configure the devices.

The execution environment model

For the smart home, the execution environment model represents home, rooms, home gateway and devices. It includes the following scales.

-Scale 0: The designer identifies the node controls (H representing a home,R representing a room, a HG representing a home gateway and D representing a device: sensor or actuator). Then, he models this scale using a bigraph. For the smart Home, this bigraph contains one H-node that represents a Home (cf. Figure 2). This rule enables to add a Room (R-node) in a Home. We apply this rule as many times as the number of rooms in the home. This number is given by the designer. Here, we have 3 rooms. The meta-rule for nesting a node is instantiated again to add a Home Gateway. The rule is: H.d 0 → H.(HG|d 0 ) -Scale 1: This scale presents a home, three rooms and a home gateway. Its bigraph is depicted in Figure 2.

-Transition from scale 1 to scale 2 (adding Devices):

The transition to the scale2 is obtained by instantiating the meta-rule for nesting a node. So, the rule is: R.d0 → R.(D|d0). This rule enables to add a device (D-node) in a room. We apply this rule as many times as the number of devices in the room. This number is given by the designer. Here, we have 5 devices.

-Scale 2: In this scale, we obtain the bigraph specifying the home, the home gateway and the 3 rooms. One of these rooms contains 5 devices. This bigraph is depicted in Figure 2.

-Transition from scale 2 to scale 3 (connecting entities within groups): The transition to scale 3 is obtained by applying the closure operation on the bigraph of the scale 2: /gt gl • scale2 This closure operation enables to link lighting communication group (i.e., link the Home Gateway with the three devices having an outer name gl: presence sensor, light sensor and lamp). It enables also to link temperature communication group (i.e., link the Home Gateway with the two other devices having an outer name gt: thermometer and air conditioner).

-Scale 3: The scale bigraph is defined in the last part of Figure 2.

Relation between execution environment and software architecture models

The transition from scale n of the execution environment model to scale 0 the software architecture model is obtained by instantiating the meta-rule for adding a sender and a receiver for devices within the temperature communication group and devices within lighting communication group. For sake of shortness, we present the instantiated rules for temperature communication group:

D gt .d 0 → D gt .(

VALIDATION WITH BPL

In order to verify the feasibility of the case study, we model our BRS model using the BPL Tool (Bigraphical Programming Languages) [START_REF] Hojsgaard | The bpl tool: A tool for experimenting with bigraphical reactive systems[END_REF]. BPL is a tool for experimenting with bigraphical models. It provides manipulation and simulation of BRS. It relies on an SML (Standard ML) compiler with an interactive mode to provide a command line interface. The language used in the BPL Tool is called BPLL (BPL Language), and it consists of a number of SML constructs which allows to write BPLL directly in SML programs.

For the implementation of our case study, we create a SML file to define the BRS for the execution environment model. Listing 1 presents a portion of this file. In this listing we define the signature of the system denoted in lines 2-5. It is the set of nodes controls. Then, we define the rules denoted in lines 7-13 (i.e., rule for adding a room, adding a home gateway and adding a device). We define also the tactics for prescribing the sequence in which reaction rules should be applied (lines 15-18 of listing 1). Finally, we define the initial system denoted in line 21 of listing 1. It represents the Home. After running the simulation, we obtain the expression of each scale in BPLL. Furthermore, to implement the software architecture model, we complete the SML file with the nodes controls (i.e., Sr representing a Sender, Rc representing a Receiver, EC representing an Event Consumer, EP representing an Event Producer and CM representing a Channel Manager), the rules and their tactics (i.e., rules for adding senders and receivers, rules for adding EBC components and rules for connecting EBC components within communication groups). After running the simulation of the software architecture model implementation, we obtain the expression of its scales in BPLL.

CONCLUSION AND FUTURE WORK

In this paper, we have focused on one of the challenging tasks of software deployment which consists in the construction of a correct deployment architecture. To tackle this issue, we have proposed a formal method based on bigraphical reactive systems. This formal language allows to guarantee a correct by construction architectures. This method provides three steps. At the first step, the designer describes the necessary information for the execution environment model, the software architecture model and the relation between them. Then, the second step consists in generating automatically all the correct deployment architectures following a multiscale modeling approach. In fact, for each model, a large scale is defined by the designer. Then, it is refined by successively adding smaller scale details. This refinement process is performed by applying specific rules. Finally, the third step is the selection of the efficient deployment architecture according to resource constraints. In our work, we have addressed communicating systems. For these systems, we have identified some information in order to ease the task for the designer in the description step. In fact, we have defined the component types for the software architecture model, the scales of each model and the transition between them and also the relation between the software architecture model and the execution environment model. Finally, in order to illustrate our approach, we have presented a case study called Smart Home and its implementation using BPL Tool. In future work, we aim to focus on the third step of our approach (i.e, selecting the efficient deployment architecture according to resource constraints). Then we intend to deal with autonomic systems by planning redeployment actions. Moreover, we are working at implementing a tool for Bigraph transformations since we have noticed some weaknesses of BPL Tool and we have noticed also that it does not meet our needs.

Figure 1 :

 1 Figure 1: Smart Home

Figure 3 : 2 -Scale 2 :

 322 Figure 3: The Bigraph at the scale 2

Listing 1 :environment model implementation 1 ( 8 H 10 ( 13 - 14 [...] 15 (

 11810131415 Execution o idp (1) --[0| ->0] --| > H o ( idp (1) '| ' R o < ->) 9 val add_HG =" add_HG "::: H o ( idp (1)) --[0| ->0] --| > -/ gt * -/ gl ) o H o ( idp (1) '| ' HG [ gt , gl ] o < ->) 11 val add_device_gt =" add_device_gt "::: 12 H o ( idp (1) '| ' R o idp (1)) --[0| ->0 ,1| ->1] --| > / gt o H o ( idp (1) '| ' R o ( idp (1) '| ' D [ gt ] o gT )) * Tactics *) 16 val rules = mkrules [ add_room , add_HG ,...] 17 val tactics_01 = 3 TIMES_DO react_rule " add_room " 18 ++ react_rule " add_HG " 19 [...] 20 (* Initial system : scale 0 *) 21 val scale0 = H o < ->

  gt ||D gt ||HG gt → /gt D gt ||(D gt |CM.gT )||HG gt The transition to the scale 2 is obtained by instantiating the two meta-rules of linking an EP to a CM and linking an EC to a CM: EP.gT ||CM.gT → /z EP z ||CM z .gT EC.gT ||CM.gT → /u EC u ||CM u .gT

	Figure 2: Scales of the execution environment model for
	Smart Home
	(Rc-node) in a device (D-node). The gT-node nested in a
	sender or a receiver denotes the temperature communication
	group. We instantiate the meta-rule again to add senders
	and receivers in the home gateway.
	So the rule is: HGgt.d0 → HGgt.(Sr.gT |Rc.gT |d0)
	6.3 The software architecture model
	This model represents senders, receivers and EBC compo-
	nents.
	-Scale 0: This scale represents the execution environment
	model including sender and receiver components.
	-Transition from scale 0 to scale 1 (adding EBC
	components): The transition to the scale 1 is obtained by
	instantiating the three meta-rules of adding EP, adding EC
	and adding CM. So, the instantiated rules for the tempera-
	ture communication group are:
	Sr.gT → Sr.EP.gT
	Rc.gT → Rc.Ec.gT
	/gt D -Scale 1: At this scale, we have the execution environ-
	ment model (home, home gateway, rooms and devices) with
	senders, receivers and EBC components. The bigraph at
	this scale is like the bigraph at the scale 2 depicted in Fig-
	ure 3 but without the green hyperedges. In this scale, we
	can obtain many Bigraphs due to the choice of the channel
	manager placement (i.e., the CM-node is deployed on one
	node belongs to the communication group).
	-Transition from scale 1 to scale 2 (connecting EBC
	components):

Sr.gT |Rc.gT |d 0 ) This rule enables to add a sender (Sr-node) and a receiver

ACKNOWLEDGMENTS

This research is supported by the Itea2's A2Nets (Autonomic Services in M2M Networks) project 1 .