=Paper=
{{Paper
|id=Vol-3067/paper8
|storemode=property
|title=A deployment approach for Smart Building applications
|pdfUrl=https://ceur-ws.org/Vol-3067/paper8.pdf
|volume=Vol-3067
|authors=Imen Abdennadher,Ismael Bouassida Rodriguez,Olfa Awled Al Hadj Abdalah
|dblpUrl=https://dblp.org/rec/conf/tacc/0001RA21
}}
==A deployment approach for Smart Building applications ==
https://ceur-ws.org/Vol-3067/paper8.pdf
A deployment approach for Smart Building
applications
Imen Abdennadher, Ismael Bouassida Rodriguez and Olfa Awled Al Hadj Abdalah
ReDCAD, University of Sfax B.P. 1173, 3038, Sfax, Tunisia
Abstract
Smart Buildings have been the subject of research for more than three decades. Since Smart buildings are
considered as the next generation of living and working environments, their development and deployment
have become a necessity. In ubiquitous computing systems, deploying Smart Building applications is
a challenge due to the important number of software components that these applications contain. To
execute such applications, their software components must be deployed on different devices in their
target environments. This process is called software deployment. In this work, we propose a deployment
approach for Smart Building applications. The deployment approach aims at transforming the Smart
Building application from an application deployed on a single machine to an application deployed on
several machines through the use of a deployment service. This service supports the redeployment at
runtime enabling the Smart Building application to adapt itself in order to handle the changes that have
been occurring during the application execution.
Keywords
Smart Buildings, software deployment, distributed environment, software components
1. Introduction
In the past, software applications were monolithic applications (application consisting of a single
component to deploy on a single machine). In recent years, current software applications have
become more and more complex and no more monolithic. They may consist of a huge number
of different components distributed over many computers connected through the network and
assembled as a system and operating together. The aim of the software deployment process is
to place an already developed application into its target environment and make it available for
use and then keep it operational. Also, software deployment was managed manually. Users
need to install their applications on their computers, using a floppy disk to copy an executable
program to another computer. However nowadays, a deployment process needs a level of
automation due to the increasing number of devices. Smart Building application is among
the software applications. The aim of Smart Buildings is improving the life quality of their
occupants. To manage a Smart Building it is necessary to develop a Smart Building application.
The deployment of Smart Building applications becomes too complex to be manually managed
due to its huge number of components which are distributed over the network .
Tunisian Algerian Conference on Applied Computing (TACC 2021), December 18–20, 2021, Tabarka, Tunisia
$ imen.abdennadher@redcad.org (I. Abdennadher); bouassida@redcad.org (I. Bouassida Rodriguez);
abdalaholfa@gmail.com (O. Awled Al Hadj Abdalah)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
In this work, we present a Smart Building case study and its associated application Smart
Building Application (SBA). The SBA was first deployed on a single machine, so we apply
our deployment approach in order to make the application distributed and to deploy this
application on several machines using a deployment service. At runtime, this service supports
the redeployment enabling the SBA to adapt itself in order to handle the changes that have
been occurring during the application execution. This paper is organized as follows: Section II
presents some concepts and definitions related to our work. In section III, we present the state
of the art. We describe the Smart Building application case study in section IV. In section V, we
present our deployment approach for Smart Buildings. In section VI, we present a deployment
scenario of the Smart Building application. Section VII concludes the paper and gives some
directions for future work.
2. Concepts and definitions
2.1. Smart Building
Smart Buildings (or intelligent buildings) have been researched and developed over the last three
decades [1]. There have been diverse discussions about the Smart Building concept. In the Smart
Building dictionary, Paul Ehrlich [2] defines a Smart Building as “a building that integrates
technology and process to create a facility that is safe, more comfortable and productive for its
occupants, and more operationally efficient for its owners."
Other definitions of the Smart Building concept are as follows:
“An automated system that: Senses what is going on indoors and outdoors. Reacts to ensure,
in the most efficient way, safe and comfortable stay in it minimizing amount of energy and
resources consumed."[3]
“ An intelligent building is a computer aided (automated) building that is designed and
centrally managed to ensure safety, comfort and productivity for its occupants as well as energy
efficiency, through sensing and communication devices."[4]
“Address both intelligence and sustainability issues by utilizing computer and intelli-
gent technologies to achieve the optimal combinations of overall comfort level and energy
consumption."[5]
Consequently, it is evident that a Smart Building has a lot of definitions, it is understood
differently by different people, but all these various definitions share some common points that
a Smart Building is :
• an automated or computerized building,
• centrally controlled and managed,
• designed to ensure safety, comfort and productivity for its occupants,
• able to sense and react to the environment change,
• aims to ensure resources usage.
2.2. Software deployment
Software deployment is a crucial step in the software life cycle. It happens between the
production and execution of software. It is a complex process that covers all post-development
activities required to place an application into its target environment and to make it available
for use [6].
2.3. Deployment process
In the literature, different activities were defined for the deployment process. Arcangeli et al.[7]
defined a set of deployment activities, referring to Carzaniga et al[8]. The proposed process
activities are presented in Figure 1:
• Release: concerns all the operations needed to prepare the software component(s) for
assembly and distribution (assembling into packages). The result of this activity is an
archive (package) that contains the software components. This package will be deployed
later on one or more deployment target hosts.
• Installation: this activity allows to insert the software component(s) into one or more
deployment target sites. It requires the software component(s) to be transferred (delivery)
and configured in order to prepare it (them) for activation.
• Activation: this activity covers all the operations required to start the software system or
to install triggers that will launch the software system at an appropriate time.
• Deactivation: refers to the activity of shutting down any executing components of the
installed system. In general, Deactivation is required for other activities such as update.
• Deinstallation: removes the software component(s) from the consumer site(s).
• Retire: concerns all the operations done on the producer site, by the software producer in
order to mark the software as obsolete. The consequence of retiring a software is that no
new version will be produced (however, current or previous versions may remain usable).
After installation, some operations are necessary to check the deployed software and provide
evolutions.
• Update: a release of a new version of a software component by the producer. It consists
in replacing the old component by a new releases.
• Adaptation : is triggered by an environmental change (user needs, resource variability,
etc). The software must be adapted in order to remain operational.
• Reorganization: modifies the logical structure of the system of components, by replacing
a component or modifying configuration parameters and/or links between components.
• Redistribution: modifies the deployment plan. It may be required when there is a change
of the network topology. It possibly demands a new location for the component(s) to
be chosen, and consists in moving the component(s) while preserving constraints, and
requirements. The term “redeployment" is used as a synonym for redistribution.
2.3.1. Deployment strategies
In the literature, software deployment can be achieved by two types of strategies: push and pull.
Release Retire
Installation Deinstallation
Activation Deactivation
Update Redistribution
Adaptation Reorganization
Software producer activities Software administrator activities
Maintenance activities
Figure 1: Life cycle of the deployment process [7].
• Push: The deployment process is started by an administrator or a supervisor node.
Software components are transferred to deployment nodes without a previous request.
In general, the supervisor node contains a program that offers a GUI. An administrator
selects software components and deployment nodes. On the other side (the deployment
nodes), there is a program that receives transferred services.
• Pull: In opposition to the push strategy, the deployment node starts the deployment
process. The user sends a deployment request, and if there is a favorable response, the
searched software component will be deployed its node.
2.3.2. Deployment categories
Two deployment categories are identified: static and dynamic deployment, called also respec-
tively: explicit and implicit.
• Static (explicit): The relation between a service or a component and a node is explicitly
defined by the administrator. This relation is realized before starting the deployment
process.
• Dynamic (implicit): The choice of a service or a component and a node is done in an
intelligent and automatic way during the deployment process.
2.3.3. Deployment control
Deployment control can be centralized or decentralized.
• Centralized: A central machine performs the deployment process. Deployment machines
are not autonomous and strictly depend on this machine. The centralized architecture
is composed of a set of deployment machines and a single deployment manager. The
deployment machines are machines on which software components will be installed. The
deployment manager manages the communication between the deployment machines. It
is also responsible of choosing software components suited to a particular machine.
• Decentralized: There is no central machine to perform the deployment process. Each
machine contains a deployment manager which interacts with neighboring machines.
This schema is well suited with pervasive computing applications.
2.3.4. Deployment modes
Two deployment modes are distinguished: initial and ulterior.
• Initial: refers to the first deployment of the application in the target environment.
• Ulterior: called also reconfiguration or redeployment. Reconfiguration is done during the
system runtime process when changes in the environment appear.
3. Software deployment tools
After presenting the deployment process, we present in the following a set of software deploy-
ment platforms. The deployment tools are deployment tools of application on a single host and
deployment tools of distributed applications. Moreover, those tools are classified into tools that
are independent of the context and other ones which depend on the context.
We have classified the study of this work into two deployment-related work-groups:
• Automatic deployment independent of the context
• Automatic deployment depend on the context
4. Related work
In the software deployment process, several tools are proposed to ensure the deployment of
software. There are many programs that are used to install and uninstall software systems from
a single machine. Examples include InstallShield [8] and Microsoft Windows [9] Installer. These
tools are not more than a compression tool with a user-friendly interface (e.g., a wizard). In
these tools, different files of software systems are compressed into self-installing archives and
are delivered to users. Users can install, uninstall and configure the software manually. They
are intended only for Windows operating systems.
DeployWare [10] is a framework for the deployment of distributed software automatically
on large scale infrastructures such as grids . This tool offers a language dedicated to the field
of deployment and a virtual machine for this language. This virtual machine is called Fractal
Deployment Framework (FDF). The deployment unit is an archive that contains the deployment
application and descriptor. The different deployment activities offered by this tool are: the
installation, activation, deactivation and uninstallation.
Photovoltaic panels
Presence sensor
Air conditioner
Lamp
Smart plug
Thermometer
Luminosity sensor
Controller
Dishwasher
Figure 2: Case study: Smart Building.
SmartFrog [11] is an advanced deployment framework, dedicated to grid infrastructures
(composed of distributed and various number of machines). It manages the deployment of
distributed systems of components, based on a specific component model. As systems change
over time, it is possible to add or remove components at runtime. SmartFrog supports several life
cycle activities: installation and uninstallation, activation and deactivation, and reorganization.
The OSGI framework (Open Services Gateway initiative) based on the Java technology [12].
Deployment within OSGi allows to install, deinstall, activate (“start” in OSGi), deactivate (“stop”
in OSGi), and update components at runtime without restarting the whole system. It allows the
deployment of Java-based components called bundles. A bundle is a Java compressed JAR file
that contains a manifest and Java class files, and other resources (libraries, files, etc.).
Kalimucho is a distributed platform for dynamic deployment on heterogeneous devices such as
desktops, laptops and mobile devices [13] . The parameters supported by this tool are the kind of
devices, and their amount of energy, CPU workload and available memory. Kalimucho supports
consumer-side deployment activities: installation and uninstallation, update, reorganization
and redistribution.
According to this study of the existing tools that ensure the deployment of the softwares,
we opt to use the OSGI framework because it offers very promising functionalities such as it
easily allows the deployment of Java applications composed of one or more OSGi bundles on
heterogeneous devices, such as personal computers, smartphones, and tablets.
5. Case study: Smart Building
To illustrate the use of our deployment approach, we introduce in the following an example of a
Smart Building illustrated in Fig. 2. The Smart Building is equipped with heterogeneous devices
(sensors like thermometer, presence sensor, luminosity sensor, power smart meter, smart plug
and actuators like air conditioner, lamp and dishwasher).
For this case study an application is developed. In the Smart Building application (SBA)
each device is presented by a software component. Such software components include: a
building manager component, a lamp component, an air conditioner component, a thermometer
component, a dishwasher component, a photovoltaic panel component, a power smart meter
component, a smart plug component, a presence sensor component, a luminosity sensor com-
ponent and a user agent component. When the device has enough capability, the software
component can be deployed on it. Otherwise, the software component is deployed on the
controller.
The principal software component is the Building Manager, deployed in the Controller
alongside the other software components. The Building Manager manages the functioning of
the building. The software components of the Smart Building application are organized into
communication sessions. Each session includes a group of components communicating in order
to achieve a specific objective. The components of the Smart Building application interact and
communicate through the Channel Manager (CM). Each session of the SBA is managed by a
CM component.
6. Deployment approach for Smart Building
In order to ensure the deployment of some software components of the SBA in various machines,
we need a Deployment tool. In our work, we used a deployment service of the FACUS framework
[14]. We used also the OSGI framework which includes components called bundles. Bundles
can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot
of the OSGi framework. For this reason, we choose to implement the Channel Managers
components as OSGi bundle. This service performs the deployment process using three entities:
The Deployment Manager, the Components Repository and the Deployment Agent.
To prepare for the deployment process of the SBA and deciding the actions to be taken during
the deployment process in order to successfully execute the deployment process, three questions
have to be answered:
– What is deployed? The first question concerns the nature of the deployed software and its
components.
Answer: The Smart Building application is a component based application. It is composed
of several software components. The components that will be deployed are the Channel
Manager and the software component of the Smart Building application which are : Build-
ing manager, air conditioner, lamp, dishwasher, smart plug, thermometer, photovoltaic
panel, luminosity sensor, presence sensor, power smart meter, user agent.
– Where is the software deployed? The second question is about the location where the
software components of the application will be deployed.
Answer: The Smart Building software components are deployed in different machines
that have enough computing capabilities and connected through the network.
– How is the deployment performed? The last question relates to the realization of the deploy-
ment process: the description of the constraints, the organization and the architecture of
the deployment descriptor.
Answer: The administrator of the Smart Building application defines the list of constraints.
The administrator knows from the beginning the architecture of the building, the number
of the devices in the building where the software components will be deployed in order
to organize the deployment descriptor.
6.1. Deployment domain and deployment descriptor
The deployment of a software is done on several consumer sites. All of these sites constitute
the ≪deployment domain≫ where the software components are deployed, and on which the
deployment of the software components is described by the administrator of the application
called ≪deployment descriptor≫.
– Deployment domain : The deployment domain is the set of networked machines or
devices (consumer sites) where the software components are deployed.
– Deployment descriptor : The deployment descriptor is a mapping between a software
component and the deployment domain (networked machines). It specified for each
software components the location where it will be deployed, the action that will be
executed on each software components (deploy, install, start, etc.).
6.2. Deployment constraints
In the Smart Building application, the administrator defines a set of constraints. It specifies
constraints related to the devices resources such as the available memory of the machines
where the software components are deployed, energy constraints which are related to the
energy consumption in the building and it defines a set of flexibility values for lamps and air
conditioners. The flexibility value for lamps is the value that the Building Manager can subtract
from the intensity value of lamps when it executes the advanced energy saving strategy. While
the flexibility value for air conditioners is the value that the Smart Building Manager can add to
the temperature value of air conditioners when it executes the advanced energy saving strategy.
The administrator of the Smart Building defines for each parameter (used memory, energy
consumption) a threshold value. Those thresholds must be respected while deploying the
software components of the application.
6.3. Deployment activities of the Smart Building application
Based on the sequences of activities earlier mentioned, we have performed a set of activities in
order to deploy the Smart Building application:
• Release: this activity is done by the producer of the Smart Building application, where
he/she prepares the different software components of the application (Building manager,
lamp, air conditioner, etc.) and assembling them into packages, those packages will be
deployed later on one or more target sites.
• Installation: this activity refers to the installation of the software components in the
target sites. This activity is done by the administrator of the application. This activity
is divided into steps done manually such as the JAR file of each software components
Figure 3: Deployment timeline
which must be placed in the targeted devices, and steps done automatically such as the
deployment of the Channel Managers. In order to achieve the steps done automatically,
the administrator prepares the deployment descriptor.
• Activation: following the preparation of the deployment plan, the application in this step
can be launched.
• Adaptation: the Smart Building application is able to adapt itself to dynamic changes.
Those changes may be resulted from a user requirement, environmental changes (such as
over consumption of the energy in the building).
• Redeployment: The redeployment activity may for example be required during an exces-
sive use of the machine memory. This activity consists of moving some components from
one machine to other while preserving the functionality of the application.
6.4. Deployment timeline
Figure 3 presents the deployment timeline related to the preparation of the deployment process
and the execution of the deployed application. Deployment activities take place before and
during the execution of the application. Before running, the application is installed and activated:
this sequence of activities is commonly named initial deployment. During the execution
of the application, environmental changes may happen. Thus, adaptation and redeployment
activities take place in the deployment process: this sequence of activities is commonly named
redeployment. Deployment runtime is the period when the deployment descriptor is running.
6.4.1. Initial deployment
In order to deploy the software components of the Smart Building application in different
devices, we use the deployment service as we mention previously.
The deployment service takes a deployment descriptor (which is prepared by the administrator
of the application) as input. This file defines what component will be deployed on each machine.
By receiving the deployment descriptor, the deployment service identifies the required software
components that must be installed on each device (CM and the software components). Then, it
connects to the deployment agents which are installed in various machines, informing them
about all needed components.
Figure 4: Execution of the deployment process scenario of the Smart Building application
6.4.2. Redeployment
The Deployment Service supports the redeployment at runtime enabling the Smart Building
application to adapt itself in order to handle the changes that have been occurring during the
application execution.
The redeployment process is executing when one of the networked machine is in a critical
state. A machine is considered in a critical state when its resources are less than the threshold
values that the administrator of the application defined. Once a machine is in a critical state, an
adaptation query is generated by the decision module [15, 16]. This module interact with the
application ensuring the selection of the most suitable redeployment of the CM components.
7. A deployment scenario of the Smart Building application
Our deployment process can be applied to many Smart Buildings examples. In order to evaluate
it, we consider a Smart Building example that is structured as follows:
• A bedroom contains: a lamp, an air conditioner, a presence sensor and a luminosity
sensor.
• A living room contains: two lamps, two air conditioners, two presence sensors and a
luminosity sensor.
• A kitchen contains: two lamps, a dishwasher, two presence sensors and two luminosity
sensors.
• A bathroom contains: a lamp, a presence sensor and a luminosity sensor.
The Figure 4 presents a deployment scenario of the Smart Building application. It includes the
sequence of events which appear in the building over the time. The horizontal axis in this figure
represents time, and the different events are marked from (1) to (6).
1 : The first event (1) in the time axis represent the initial deployment which includes under
tasks which are:
• The administrator of the SBA defines a set of constraints which must be respected during
the execution of the Smart Building application. In our work, we are interested to the
constraints related to the resources of machines like the memory consumption of the
machines. The administrator defined a threshold value for the memory consumption
(25%).
• The administrator makes a correspondence between the software components of the
application and the device where the component will be deployed on, and prepare the
deployment descriptor.
• When the deployment descriptor is prepared, the administrator executes the Building
manager and the initial deployment is starting. Afterwards, the channel managers are
deployed in the controller and the software components are deployed in the targeted
devices.
2 : The second event (2) represents the initial situation of our deployment process, where all
the devices are turned off.
3 : The third event (3) is the arrival of the user requirements. The user turn on a lamp with
an intensity equal to 1000 Lumen through its device interface.
4 : The fourth event (4) the user turns on an air conditioner with temperature value equal to
25C through its device interface.
5 : While communicating with the Building Manager, the memory consumption in the
Controller increases. The Building manager detects that the Controller is in critical state, it
sends an adaptation request to the Decision module. This module is responsible of choosing the
most suitable redeployment of the CM components. Then this module sends the new deployment
descriptor to the Building Manager. The Building Manager sends the deployment descriptor to
the Deployment Service which indicates for each deployment Agent the components that it
must deploy in each device.
6 : The Building Manager receives the new deployment descriptor the redeployment in exe-
cuted automatically. The deployment service receives the deployment descriptor and connects
to the deployment agents indicating the new location of the CM components.
8. conclusion and future work
In this paper, we propose a deployment approach for the Smart Building application. First, we
present tools that ensure the deployment of software applications. Then, we briefly present
the case study Smart Building. After that, we present our deployment approach for the SBA.
Finally, we apply the deployment approach on a Smart Building example using the deployment
service which ensures the deployment of some software components of the application in a
set of machines. Also, the deployment service supports the redeployment at runtime enabling
the SBA to adapt itself in order to handle the changes that have been occurring during the
execution of the application.
As future work, we aim to evaluate our approach through real world experiments.
Acknowledgments
This work was partially supported by the LABEX-TA project MeFoGL:"Méhodes Formelles pour
le Génie Logiciel".
References
[1] A.H. Buckman M. Mayfield Stephen B.M. Beck, “What is a Smart Building", Smart and
Sustainable Built Environment, vol. 3, pp.92–109, September 2014.
[2] P. Ehrlich, “What is an intelligent building?", Building Intelligence Group, 2007.
[3] G.D. Abowd, “Classroom 2000: An experiment with the instrumentation of a living educa-
tional environment", IBM Systems Journal, 1999.
[4] W. Haijiang L.J. KwokWai S. Wang, “Intelligent building research: a review, In Software
Engineering Research", Management and Applications, pp. 143–159, 2005.
[5] Dounis A.I. Wang Z., Wang L. and Yang R., “Integration of plug-in hybrid electric vehicles
into energy and comfort management for smart building", Smart Buildings and Demand
Response , 260–266, 2012.
[6] A. Heydarnoori, “Deploying component based applications: Tools and techniques", In
Software Engineering Research, Management and Applications, 2008.
[7] R. Boujbel J.P Arcangeli and S. Leriche, “Automatic deployment of distributed software
systems: Definitions and state of the art", Journal of Systems and Software (2015), 198–218.
[8] InstallShield Developer, https://www.installshield.com.
[9] Microsoft Windows Installer, https://www.microsoft.com, 2006.
[10] A. Flissi J. Dubus N. Dolet P. Merle, “Deploying on the Grid with DeployWare", 2008.
[11] P. Goldsack J. Guijarro S. Loughran A. Coles A. Farrell A. Lain P. Murray P. Toft, “The
SmartFrog Configuration Management Framework", Operating Systems Review , pp 16–25,
2009.
[12] OSGi Alliance, “Osgi service platform core specification",
http://www.osgi.org/Specifications, 2007.
[13] C. Louberry P. Roose M. Dalmau, “Kalimucho: Contextual Deployment for QoS Manage-
ment", Distributed Applications and Interoperable Systems, 2011.
[14] G. Sancho, “Adaptation d’architectures logicielles collaboratives dans les environnements
ubiquitaires. Contribution à l’interopérabilité par la sémantique ", Université des Sciences
Sociales - Toulouse I , 2010, PhD Theses.
[15] I. Abdennadher , I. Bouassida Rodriguez , M. Jmaiel, “A Design Guideline for Adaptation
Decisions in the Autonomic Loop", Procedia Computer Science, 2017.
[16] I. Abdennadher , “DAACS : a Decision Approach for Autonomic Computing Systems",
Journal of supercomputing, 2021.