An IoT application development using IoTSuite Saurabh Chauhan, Pankesh Patel ABB Corporate Research, Bangalore, India
Abstract Application development in the Internet of Things (IoT) is challenging because it involves dealing with issues that
arXiv:1609.01676v1 [cs.SE] 6 Sep 2016
attribute to different life-cycle phases. First, the application logic has to be analyzed and then separated into a set of distributed tasks for an underlying network. Then, the tasks have to be implemented for the specific hardware. Moreover, we take different IoT applications and present development of these applications using IoTSuite. In this paper, we introduce a design and implementation of ToolSuite, a suite of tools, for reducing burden of each stage of IoT application development process. We take different class of IoT applications, largely found in the IoT literature, and demonstrate these IoT application development using IoTSuite. These applications have been tested on several IoT technologies such as Android, Raspberry PI, Arduino, and JavaSE-enabled devices, Messaging protocols such as MQTT, CoAP, WebSocket, Server technologies such as Node.js, Relational database such as MySQL, and Microsoft Azure Cloud services. Keywords: Internet of Things, Wireless Sensor Networks, Ubiquitous/Pervasive Computing, Programming Framework, Toolkit, Domain-specific languages, Development Life-cycle
1. Introduction
the development of such applications. In the following, we discuss one of such applications.
Recent technological advances in computer and communication technology have been fueling a tremendous growth in a number of smart objects (or things) [19]. In the Internet of Things1 , these “things” acquire intelligence, thanks to the fact that they access information that has been aggregated by other things. For example, a building interacts with its residents and surrounding buildings in case of fire for safety and security of residents, offices adjust themselves automatically accordingly to user preferences while minimizing energy consumption, or traffic signals control in-flow of vehicles according to the current highway status [7, 1]. It is the goal of our work to enable
Email addresses:
[email protected] (Saurabh Chauhan),
[email protected] (Pankesh Patel) 1 http://www.grifs-project.eu/data/File/CASAGRAS% 20FinalReport%20(2).pdf submitted as Technical report
1.1. Challenges and contributions Application development in the IoT is challenging because stakeholders2 have to address issues that are attributed to different life cycles phases, including development, deployment, and maintenance [4]. At the development phase, the application logic has to be analyzed and separated into a set of distributed tasks for the underlying network consisting of a large number of heterogeneous entities. Then, the tasks have to be implemented for the specific platform of a device. At the deployment phase, the application logic has to be deployed onto a large number 2 we will use the term stakeholders as used in software engineering to mean people, who are involved in the application development. Examples of stakeholders defined in [18] are software designer, developer, domain expert, technologist, etc.
September 7, 2016
2. IoT application development process
of devices. Manual effort in above two phases for hundreds to thousands of heterogeneous devices is a time-consuming
This section presents our development framework that
and error-prone process.
separates IoT application development into different con-
An important challenge that needs to be addressed in
cerns, namely domain, platform, functional, and deploy-
the IoT is to enable the rapid development of applications
ment. It integrates a set of high-level modeling languages
with minimal effort by stakeholders involved in the pro-
to specify such concerns. These languages are supported
cess [11, 13]. In our previous publications [15, 5, 14], we
by automation techniques at various phases of application
have provided a complete tour of our IoT application de-
development process. Stakeholders carry out the following
velopment process, summarized in Section 2. This paper
steps in order to develop an IoT using our approach:
goes beyond it. In particular, it describes implementation technologies, tools, language used and their rationales of
2.1. Domain Concern
choosing them [17, 6, 12]. Although various efforts exist in
This concern is related to concepts that are specific to
literature for making IoT application development easier,
a domain (e.g., building automation, transport) of an IoT.
very few of them are publicly available for stakeholders to
The stakeholders task regarding such concern consists of
choose from. Given the usefulness of open source, our aim
the following step:
is to provide an opportunity to community for the creation
Specifying and compiling domain specification. The
of novel software engineering tools and the conduction of
domain expert specifies a domain specification using the
novel research for IoT application development.
Domain Language (DL) (Step 1 in Figure 1). The domain
The main contribution of this paper is an implemen-
specification includes specification of resources, which are
tation of ToolSuite, a suite of tools, for reducing burden
responsible for interacting with Entities of Interest (EoI).
at different phases for IoT application development (de-
This includes tags (identify EoI), sensors (sense EoI), ac-
tail in Section 3). Moreover, we take different class of IoT
tuators (affect EoI), and storage (store information about
applications [16] and describe an application development
EoI). In the domain specification, resources are specified
process using IoTSuite.
in a high-level manner to abstract low-level details from
Outline. The remainder of this paper is organized
the domain expert.
as follows: Section 2 presents the development framework that includes the proposed modeling languages and au-
2.2. Functional Concern
tomation techniques. Section 3 presents the implementa-
This concern is related to concepts that are specific to
tion of the development framework and describes imple-
functionality of an IoT application. An example of a func-
mentation technologies, tools, and languages used. Sec-
tionality is to open a window when an average tempera-
tion 4 describes step by step IoT application development
ture value of a room is greater than 30◦ C. The stakehold-
process using IoTSuite. It also focus on different class of
ers task regarding such concern consists of the following
application to demonstrate application development using
steps:
IoTSuite. Finally, in Section 5, we conclude this article
Specifying application architecture. Referring the do-
and briefly mention some of future directions.
main specification, the software designer specifies an application architecture using the Architecture Language (AL)(Step 2 in Figure 1). It consists of specification of computational services and interaction among them. A com2
5
User Interface Designer
User Interaction Compilation of Spec. User interaction Spec
UI framework
Software Designer
Domain concern
6
User Interface (UI) Code
Platform concern Generated code For device N
Sensor, Actuator, Storage Framework
Wrapper
4
Domain expert
Domain Framework
Platform concern 9
1 8 Domain Spec.
Deployment Spec.
Compilation of Domain Spec.
Runtime System
Mapping files Linker
Mapper
7
Deployment concern
Network Manager
In-Built Framwrk
Generated code For device N Custom Code
3 Wrapper
Architecture Spec.
2 Software Designer
Compilation of Architecture Spec.
Architecture Framework
Application Developer Runtime System
Functional concern
Figure 1 – IoT application development: the overall process
2.3. Platform Concern
putational service is fueled by sensors and storage defined in the domain specification. They process inputs data and
This concern specifies the concepts that fall into com-
take appropriate decisions by triggering actuators defined
puter programs that act as a translator between a hard-
in the domain specification. The application architecture
ware device and an application. The stakeholders task
consists of common operations and custom components
regarding such concern consists of the following steps:
that are specific to the application logic.
Generating device drivers. The compilation of domain
Implementing application logic. The compilation of
specification generates a domain framework (Step 4 in
an architecture specification generates an architecture frame- Figure 1). It contains concrete classes corresponding to work (Step 3 in Figure 1). The architecture framework
concepts defined in the domain specification. The con-
contains abstract classes, corresponding to each compu-
crete classes contain concrete methods to interact with
tational service, that hide interaction details with other
other software components and platform-specific device
software components and allow the application developer
drivers, described in our work [9, p. 75]. We have inte-
to focus only on application logic. The application devel-
grated existing open-source sensing framework3 for An-
oper implements only abstract methods of generated ab-
droid devices. Moreover, we have implemented sensing and
stract classes, described in our work [9, p. 73]. We have
actuating framework for Raspberry Pi and storage frame-
integrated a framework for common operations. This fur-
work for MongoDB, MySQL, and Microsoft AzureDB. So,
ther reduces the development effort for commonly found 3 http://www.funf.org/
operations in IoT application and provides re-usability. 3
the device developers do not have to implement platform-
randomly and allocates computational services to the se-
specific sensor, actuator, and storage code.
lected devices.
Specifying user interactions. To define user interac2.5. Linking
tions, we present a set of abstract interactors, similar to
The linker combines the code generated by various stag-
work [2], that denotes information exchange between an
es and creates packages that can be deployed on devices (St-
application and a user. The software designer specifies
ep 9 in Figure 1). This stage supports the application de-
them using User Interaction Language (UIL) (Step 5 in
ployment phase by producing device-specific code to result
Figure 1). Implementing user-interface code.
in a distributed software system collaboratively hosted by
Leveraging the
individual devices, thus providing automation at the de-
user interaction specification, the development framework
ployment phase.
generates a User Interface (UI) framework (step 6 in Fig-
The final output of linker is composed of three parts:
ure 1). The UI framework contains a set of interfaces and
(1) a runtime-system runs on each individual device and
concrete classes corresponding to resources defined in the
provides a support for executing distributed tasks, (2) a
user interaction specification. The concrete classes con-
device-specific code generated by the linker module, and
tain concrete methods for interacting with other software
(3) a wrapper separates generated code from the linker
components. The user interface designer implements inter-
module and underlying runtime system by implementing
faces. These interfaces implement code that connects ap-
interfaces.
propriate UI elements to concrete methods. For instance, a user initiates a command to heater by pressing UI element
3. Components of IoTSuite
such as button that invokes a sendCommandToHeater() concrete method.
This section presents the implementation of the proposed IoT application development process discussed in
2.4. Deployment Concern
Section 2. In particular, it describes implementation tech-
This concern is related to deployment-specific concepts
nologies, tools, language used and their rationales of choos-
that describe the information about a device and its prop-
ing them. Figure 2 shows the various components at each
erties placed in the target deployment. It consists of the
phase of application development that stakeholders can
following steps:
use, described below.
Specifying target deployment. Referring the domain • Editor: It helps stakeholders to write high-level spec-
specification, the network manager describes a deployment
ifications, including domain, architecture, userinter-
specification using the Deployment Language (DL) (Step 7
action, and deployment specification.
in Figure 1). The deployment specification includes the details of each device as well as abstract interactors specified
• Compiler: It parses the high-level specifications
in the user interaction specification.
and translates them into the code that can be used
Mapping. The mapper takes a set of devices defined
by other components in the system.
in the deployment specification and a set of computation
• Mapper: It maps computational services described
components defined in the architecture specification(Step-
in an architecture specification to devices listed in an
8 in Figure 1). It maps computational service to a device.
deployment specification.
The current version of mapper algorithm [9] selects devices 4
5 Editor for Writing UI Spec.
Domain concern
6
UI Framework
User Interface Designer
Compiler for User interaction Spec.
Eclipse IDE for implementing UI framework
Software Designer
Platform concern Generated code For device N
4 Domain expert
Domain Framework
Eclipse IDE for implementing domain framework
Wrapper
Platform concern 9
1
8 Editor for Writing Deployment Spec.
Compiler for Editor for Domain Spec. Writing Domain Spec.
Runtime System
Mapping files Linker
Mapper
7 Network Manager
Deployment concern Arch. Framework
Editor for Writing Arch. Spec.
2 Software Designer
Generated code For device N
3 Wrapper
Compiler for Architecture Spec.
Eclipse IDE for implementing arch. framework
Application Developer Runtime System
Functional concern
Figure 2 – Overview of components in IoTSuite.
• Linker: It combines and packs code generated by
specifying an application architecture to aid the software
various stages of compilation into packages that can
designer, (3) editor for specifying an userinteraction to aid
be deployed on devices.
the software designer and, (4) editor for specifying a deployment scenario to aid the network manager.
• Runtime system: It is responsible for a distributed
We take the editor for domain specification as an ex-
execution of an application.
ample to demonstrate an editor support provided by IoTEach component is described in detail in the following
Suite, illustrated in Figure 3. The zone 1 shows the ed-
sections.
itor, where the domain expert writes a domain specifica-
3.1. Editor
tion. The zone 2 shows the context menu, where the domain expert invokes the compiler for domain specification
The editor provides supports for specifying high-level
to generate a framework.
textual languages with the facilities of outline view, syntax coloring, code folding, error checking, rename re-factoring,
Features of editor. We use Xtext4 for a full fledged ed-
and auto completion. The editor support is provided at
itor support, similar to work in [3]. The Xtext is a frame-
different phases of IoT application development to help
work for a development of domain-specific languages, and
stakeholders illustrated in Figure 2: (1) editor for speci-
provides an editor with features such as syntax coloring, 4 http://www.eclipse.org/Xtext/
fying a domain to aid the domain expert, (2) editor for 5
Figure 3 – Editor support for writing domain specification in IoTSuite.
Figure 4 – IoTSuite editor feature: Outline view
error checking, auto completion, rename re-factoring, out-
highlighting its structure. This is useful for quick
line view, and code folding:
navigation. As shown in Figure 4, vocab.mydsl file contains a large number of structures, sensors, and
• We implemented Outline/Structure view feature, wh-
actuators, than from outline view by just clicking on
ich is displayed on top most right side of the screen (Refer Figure 4).
particular structure (e.g., TempStruct) it navigates
It displays an outline of a file 6
Figure 5 – IoTSuite editor feature: Syntax coloring
ification file.
to TempStruct definition in the vocab.mydsl. So, developers don’t need to look into an entire file.
• The Auto completion is used to speed up writing text
• Using syntax coloring feature, keywords, comments,
in specification files. In order to use auto completion
and other datatype elements are appeared in colored
feature, developer needs to press ctrl+space key at
text. Here, resources, and tags are appeared in
current cursor position, so it will provide suggestion.
colored text as shown in Figure 5.
Here in BadgeReader definition, if developer writes Bad and press ctrl+space than it will suggest devel-
• Using code folding, developer can collapse parts of a
oper to write BadgeStruct (Refer Figure 7).
file that are not important for current task. In order to implement code folding, click on dashed sign
3.2. Compiler
located in left most side of the editor. When devel-
The compiler parses high-level specifications and trans-
oper clicked on dashed sign, it will fold code and sign
lates them into code that can be used by other components
is converted to plus. In order to unfold code, again
in the system. This component is composed of two mod-
click on plus sign. As shown in Figure 6, the code is
ules: (1) parser. It converts high-level specifications into
folded for TempStruct, and BadgeStruct.
data structures that can be used by the code generator.
• The error checking feature guides developer if any
(2) code generator. It uses outputs of the parser and pro-
error is there. An error in the file is marked au-
duces files in a target implementation language. In the
tomatically e.g., violation of the specified syntax or
following, each of these modules are discussed.
reference to undefined elements. Error checking indi-
Parser. It converts high-level specifications (domain, ar-
cates if anything is missing/wrong in particular spec-
chitecture, userinteraction, and deployment specification) 7
Figure 6 – IoTSuite editor feature: Code folding
Figure 7 – IoTSuite editor features: Error checking & Auto completion
into data structures that can be used by the code gen-
tor [8]. The ANTLR parser is a well-known parser gener-
erator. Apart from this core functionality, it also checks
ator that creates parser files from grammar descriptions.
syntax of specifications and reports errors to stakeholders.
Code generator. Based on parser outputs, the code gen-
The parser is implemented using ANTLR parser genera-
erator creates required files. It is composed of two sub8
Figure 8 – Generated architecture framework in Eclipse
modules: (1) core-module, (2) plug-in. The core-module
grammar to aid stakeholders. (2) compiler for an architec-
manages a repository of plug-ins. Each plug-in is specific
ture specification. It translates an architecture specifica-
to a target implementation code. The target code could be
tion and generates an architecture framework to aid the
in any programming language (e.g., Java, Python). Each
application developer. The both generated frameworks
plug-in is defined as template files, which the core-module
are compatible with Eclipse IDE. For example, Figure 8
uses to generate code. The key advantage of separating
shows a generated architecture framework containing Java
core-module and plug-in is that it simplifies an implemen-
files ( 1 in Figure 8) in Eclipse IDE. 2 in Figure 8 shows
tation of a new code generator for a target implementation.
a generated Java file in the architecture framework for a
The plug-ins are implemented using StringTemplate
RoomController. Note that the generated framework con-
5
Engine , a Java template engine for generating source code
tains abstract method ( 3 in Figure 8), which are imple-
or any other formatted text output. In our prototype im-
mented by the application developer using Eclipse IDE.
plementation, the target code is in the Java programming 3.3. Mapper
language compatible with Eclipse IDE. However, the code
The mapper produces a mapping from a set of compu-
generator is flexible to generate code in any object-oriented
tational services to a set of devices. Figure 9 illustrates
programming language, thanks to the architecture of the
the architecture of the mapper component. This compo-
code generator that separates core-module and plug-ins.
nent parses a deployment and architecture specification.
We build two compilers to aid stakeholders shown in Figure 2.
(1) compiler for a domain specification.
The parser converts high-level specifications into appro-
It
priate data structures that can be used by the mapping
translates a domain specification and generates a domain
algorithm. The mapping algorithm maps computational
framework, and a customized architecture and deployment
services described in the architecture specification to de5 http://www.stringtemplate.org/
vices described in the deployment specification and pro9
Deployment Spec. Parser Architecture Spec.
Data structures
Mapping Algorithm
Mapping decisions
Code Generator
Mapping files
Mapper Figure 9 – Architecture of the mapper component in IoTSuite.
duces mapping decisions into appropriate data structures.
into three parts: (1) middleware: It runs on each indi-
The code generator consumes the data structures and gen-
vidual device and provides a support for executing dis-
erates mapping files that can be used by the linker com-
tributed tasks. (2) wrapper : It plugs packages, generated
ponent.
by the linker module, and middleware. (3) support library:
In our current implementation, this module randomly
It separates packages, produced by the linker component,
maps computational services to a set of devices. However,
and underlying middleware by providing interfaces that
due to generality of our framework, more sophisticated
are implemented by each wrapper. The integration of a
mapping algorithm can be plugged into the mapper com-
new middleware into IoTSuite consists of an implementa-
ponent.
tion of the following interfaces in the wrapper: publish(). It is an interface for publishing data from a
3.4. Linker
sender. The definition of this interface contains: an event The linker combines and packs code generated by var-
name (e.g., temperature), event data (e.g., a temperature
ious stages of compilation into packages that can be deployed on devices.
value, Celsius), and publisher’s information such as loca-
It merges a generated architecture
tion of a sender.
framework, application logic, mapping code, device drivers, subscribe(). It is an interface for receiving event noti-
and domain framework. This component supports the de-
fications. An interest of events is expressed by sending a ployment phase by producing device-specific code to result subscription request, which contains: a event name (e.g., in a distributed software system collaboratively hosted by temperature), information for filtering events such as reindividual devices. gions of interest (e.g., a RoomAvgTemp component wants to
The current version of the linker generates packages
receive events only from a current room), and subscriber’s for Android, Node.js, and JavaSE platform. Figure 10 ilinformation. lustrates packages for Android devices ( 1 in Figure 10), command(). It is an interface for triggering an action of an
JavaSE target devices ( 2 in Figure 10), and Node.js de-
actuator. A command contains: a command name (e.g.,
vices ( 3 in Figure 10) and imported into Eclipse IDE.
switch-on Heater), command parameters (e.g., set tem-
In order to execute code, these packages still need to be
perature of Heater to 30◦ C), and a sender’s information.
compiled by a device-level compiler designed for a target
request-response(). It is an interface for requesting
platform.
data from a requester. In reply, a receiver sends a re3.5. Runtime system
sponse. A request contains a request name (e.g., give pro-
The main responsibility of the runtime system is a dis-
file information), request parameters (e.g., give profile of
tributed execution of IoT applications [10]. It is divided
person with identification 12), and information about the requester. 10
Figure 10 – Packages for target devices in Eclipse
The current implementation of IoTSuite uses the MQTT middleware. It enables interactions among Android de-
application development. Figure 11 illustrates use of our plug-in at various phases of IoT application development:
vices, Node.js-enabled devices, and JavaSE-enabled de-
1. Vocab.mydsl ( 1 in Figure 11) – using which the
vices. The current wrapper implementation for the MQTT
domain expert can describe and compile a domain
middleware is available at URL6 .
specification of an application domain. 2. Arch.mydsl ( 2 in Figure 11) – using which the soft-
3.6. Eclipse plug-in
ware designer can describe and compile an architec-
We have integrated the above mentioned components
ture specification of an application.
as Eclipse plug-in to provide end-to-end support for IoT
3. Userinteraction.mydsl ( 3 in Figure 11) – using which the software designer can describe and compile an
6 https://github.com/pankeshlinux/ToolSuite
userinteraction specification of an application. 11
Figure 11 – Eclipse plug-in for IoT application development.
4. Deploy.mydsl ( 4 in Figure 11) – using which the
cludes concepts that are specific to functionality of IoT),
network manager can describe a deployment speci-
userinteraction specification (defines what interaction are
fication of a target domain and invoke the mapping
required by an application), and deployment specification -
component. The network manager can combines and
(describes a device and its properties in a target deploy-
packs code generated by various stages of compila-
ment). Stakeholders specify high-level specifications using
tion into packages that can be deployed on devices.
IoTSuite-Eclipse-Plugin7 . 4.1. Personalized HVAC application:
4. A step-by-step applications development using
A home consists of several rooms, each one is instru-
IoTSuite
mented with several heterogeneous entities for providing This section describes each step of IoT application de-
resident’s comfort. To accommodate a resident’s prefer-
velopment process using IoTSuite. Application develop-
ence in a room, a database is used to keep the profile
ment using IoTSuite is a multi-step process and focuses on
of each resident, including his/her preferred temperature
design, implement, and deployment phases to develop IoT
level. An RFID reader in the room detects the resident’s
applications. We take different class of application (SCC
entry and queries the database service. Based on this,
(Sense-Compute-Control), End-User-Interaction, and Data
the thresholds used by the room device (Heater) are up-
Visualization) as an example to demonstrate application
dated as shown in Figure 12. Developers need to follow
development using IoTSuite.
following steps to develop above discussed application us-
Specifying high-level specifications. It includes specifi-
ing IoTSuite.
cations of domain specification (includes concepts that are specific to domain of IoT), architecture specification (in-
7 https://github.com/chauhansaurabhb/IoTSuite-Eclipse-Plugin
12
For instance, a user’s profile is accessed from storage by a badgeID (Listing 1, lines 19-20). 1
Heater
2
tempValue : double ;
4
u n i t O f M e a s u r e m e n t : String ;
badgeID : String ;
7
badgeEvent : String ;
9 10 11 12
Badge Reader
ProfileDB
Legend
X
Y
X publishes data and Y subscribes
X X commands Y
Y
X
BadgeReader generate badgeDetected : BadgeStruct ; generate b ad g eD i sa p pe a re d : BadgeStruct ;
14
Heater
15
action SetTemp ( setTemp : TempStruct ) ;
16
action Off () ;
19
Actuator
Storage
tags :
actuators :
18
Computational Service
resources :
13
17
RFID Reader
BadgeStruct
6
8
Proximity
TempStruct
3
5
RoomController
structs :
20
Y
storages : ProfileDB generate profile : TempStruct accessed - by badgeID : String ;
Listing 1 – Code snippet of domain spec.
X requests Y, Y replies X
Compilation of domain specification. To compile domain specification (vocab.mydsl file), Right click on the vocab.mydsl file (Step 1 ) and click on Compile Vocab
Figure 12 – Dataflow of Personalized-HVAC Application
option (Step 2 ) as shown in Figure 13. Specifying Domain specification. Developer specifies
Architecture specification. Developer specifies architec-
domain specification using IoTSuite as shown in Listing 1.
ture specification using IoTSuite as shown in Listing 2. It
Each resource is charaterized by types of information it
is described as a set of computational services. It con-
generates or consumes. A set of information is defined us-
sists of two types of computational services: (1) Common
ing the structs keyword (Listing 1, line 1). For instance, a
component specifies common operations (e.g., average ,
BadgeReader (lines 10-12) may generate a badgeDetected
count , sum ) in the application logic. (2) Custom specifies
and badgeDisappeared. This information is defined as
an application specific logic. For instance, the Proximity
BadgeStruct and its two fields (6-7). A Heater is set ac-
component is a custom component that coordinates events
cording to a user’s temperature preference illustrated in
from BadgeReader with the content from ProfileDB as
Listing 1, lines 14-16. The SetTemp action takes a user’s
shown in Figure 12. Each computational service is de-
temperature preference shown in line 15. A set of storage is
scribed by a set of inputs and outputs.
declared using the storages keyword (Listing 1, line 17).
the Proximity consumes badgeDetected and badgeDis-
A retrieval from the storage requires a parameter, speci-
appeared (Listing 2, lines 4-5), request to ProfileDB to
fied using the accessed-by keyword (Listing 1, line 19).
access user’s profile (Listing 2, line 6) and generates temp13
For instance,
Figure 13 – Compilation of domain spec.
1 2 3
Pref (Listing 2, line 7). Command is issued by a compu-
the arch.mydsl file (Step 1 ) and click on Compile Arch
tational service to trigger an actions. For instance, the
option (Step 2 ) as shown in Figure 14.
RoomController issues a SetTemp command (Listing 2,
Import application logic package. To import applica-
line 10) with a setTemp as an argument to Heater (List-
tion logic package, click on File Menu (Step 1 ), and select
ing 1, lines 14-15).
Import option (Step 2 ) as shown in Figure 15.
Proximity consume badgeDetected from BadgeReader ;
5
consume b a dg e Di s ap p ea r ed from BadgeReader ;
6
request profile to ProfileDB ;
8 9
logic package, browse to Template path (Step 1 ), select
Custom :
4
7
Locate application logic package. To locate application
computationalServices :
application logic package (Step 2 ), and click on Finish button (Step 3 ) as shown in Figure 16. Implement application logic. The application logic proj-
generate tempPref : TempStruct ;
ect contains a generated framework that hides low-level
RoomController
details from a developer and allows the developer to fo-
consume tempPref from Proximity ;
10
command SetTemp ( setTemp ) to Heater ;
11
command Off () to Heater ;
cus on the application logic. The developer writes application specific logic in logic package. Listing 3 and 4 show generated Java programming framework from the
Listing 2 – A code snippet of architecture spec.
architecture specification, defined in Listing 2. To impleCompilation of architecture specification. To compile
ment application logic of Proximity component, devel-
architecture specification (arch.mydsl file), Right click on
opers have to implement the generated abstract methods 14
Figure 14 – Compilation of architecture spec.
illustrated in Listing 3. The Proximity component receives the badgeDetected and badgeDisappeared events from the BadgeReader and coordinates with ProfileDB
5 6 7 8
component for user-temperature preference defined in List-
public class LogicProximity extends Proximity {
public LogicProximity ( P ub S ub M id d le w ar e pubSubM , Device deviceInfo , Object ui , Context
9
ing 2, lines 3-6. To implement this logic, three methods (onNewbadgeDetected, onNewbadgeDisappeared, and
myContext ) { super ( pubSubM , deviceInfo ) ;
10 11
onNewprofileReceived) have to implemented as shown in
}
12
Listing 3. It request to ProfileDB for user’s preference using onNewbadgeDetected method, turn off Heater using
13
@Override
14
public void o n N e w b a d g e D e t e c t e d ( BadgeStruct arg ) {
onNewbadgeDisappeared method, and generate tempPref
// Request profileDB for his preference
15
using onNewprofileReceived method which is consumed by the RoomController defined in Listing 2, line 9. In similar ways, developer implements application logic of RoomController component using onNewtempPref method. It
getprofile ( arg . getbadgeID () ) ;
16 17
}
18
@Override
19
public void o n N e w b a d g e D i s a p p e a r e d ( BadgeStruct
20
// Person is leaving the room . Turn off the
21
TempStruct tempStruct = new TempStruct ( -100 ,
arg ) {
issues a SetTemp and Off commands to Heater using onNewtempPref method as illustrated in Listing 4. 1
package logic ;
2
import android . content . Context ;
3
import iotsuite . semanticmodel .*;
4
import framework .*;
heater .
"C"); settempPref ( tempStruct ) ;
22 23
15
}
Figure 15 – Import application logic package
24
public void o n N e w p r o f i l e R e c e i v e d ( TempStruct arg
25
TempStruct tempStruct = new TempStruct ( arg .
26
// Set temperature to RoomController
12
settempPref ( tempStruct ) ;
13
10
public L o g i c R o o m C o n t r o l l e r ( Pu b Su b Mi d dl ew a re
) {
pubSubM , Device deviceInfo , Object ui , Context
11
gettempValue () , " C " ) ;
27
}
28 29
}
package logic ;
2 3
15
@Override
16
public void onNewtempPref ( TempStruct arg ) {
17
if ( arg . gettempValue () == -100) {
18
// It means that person is leaving the room
19 20
import iotsuite . pu b su b mi d dl e wa r e . P ub S ub M id d le w ar e
4
import android . content . Context ;
5
import iotsuite . semanticmodel .*;
6
import framework .*;
7
9
} else { // If the person is entering to the room
22
// set temperature according to his
23
double tempValue = arg . gettempValue () ;
24
TempStruct tempStruct = new TempStruct (
then ,
preference
public class L o g i c R o o m C o n t r o l l e r extends RoomController {
Off () ; // Set the Off () command
21
;
8
}
14
Listing 3 – The implementation of the Java abstract class Proximity written by the developer. 1
myContext ) { super ( pubSubM , deviceInfo ) ;
tempValue , 25 26
16
arg . g e t u n i t O f M e a s u r e m e n t () ) ; SetTemp ( tempStruct ) ;
Figure 16 – Locate application logic package
}
28 29
age device contains the database field that specifies the
}
27
installed database. This field is used to select an appro-
}
priate storage driver. For instance, DatabaseSrvDevice
Listing 4 – The implementation of the Java abstract class
(line 8) runs ProfileDB (line 12) component implemented
RoomController written by the developer.
in MySQL database (line 14) as illustrated in Listing 5.
Deployment specification. Developer specifies deployment specification using IoTSuite as shown in Listing 5.
1 2
It includes properties such as location that defines where
devices : BadgeReaderMgmtDevice :
3
location :
a device is deployed, resources define component(s) to
4
Room :1;
be deployed on a device, language-platform is used to
5
platform : NodeJS ;
6
resources : BadgeReader ;
7
protocol : mqtt ;
generate an appropriate pack-age for a device, protocol specifies a run-time system in-stalled on a device to interact with other devices. Listing 5 shows a code snippet to illustrate these concepts. BadgeReaderMgmtDevice is located in room#1 (line 4), BadgeReader is attached with
8 9 10 11
DatabaseSrvDevice : location : Room : 1; platform : JavaSE ;
12
resources : ProfileDB ;
the device (line 6) and the device driver code for these
13
protocol : mqtt ;
two component is in NodeJS (line 5), mqtt runtime system
14
database : MySQL ;
15
ResourceMgmtDevice1 :
is installed on BadgeReaderMgmtDevice (line 7). A stor-
17
16
location : Room : 1;
17 18
platform : JavaSE ;
19
resources : ;
20
protocol : mqtt ;
21 22
location : Fire State
Room : 1;
24
platform : JavaSE ;
25
resources : ;
RoomAvgTemp
protocol : mqtt ;
27
H ea t er M gm t De v ic e :
28
location :
Temperature Sensor
Smoke Sensor
Room : 1;
29 30
Fire Controller
ResourceMgmtDevice2 :
23
26
EndUserApp
Alarm
Legend
platform : JavaSE ;
31
resources : Heater ;
32
protocol : mqtt ;
X Computational Sensor Service
Actuator
User interface
Y
X publishes data and Y subscribes
X
Y
X commands Y
Listing 5 – Code snippet of deployment spec. Compilation of deployment spec. Right click on de-
Figure 19 – Dataflow of Fire Detection Application
ploy.mydsl file (Step 1 ) and selecting Compile Deploy (Step 2 ) as shown in Figure 17 generates a deployment
Specifying Domain specification. Developer specifies
packages.
domain specification using IoTSuite as shown in Listing 6.
Deployment of generated packages. The output of com-
Each resource is charaterized by types of information it
pilation of deployment specification produce a set of plat-
generates or consumes. A set of information is defined
form specific project/packages as shown in Figure 18 for
using the structs keyword (Listing 6, line 1). A set of
devices, specified in the deployment specification (Refer
sensors is declared using the sensors keyword (Listing 6,
Listing 5).
These projects compiled by device specific
line 9). Each sensor produces one or more sensor mea-
compiler designed for the target platform. The generated
surements along with the data-types specified in the data
packages integrate the run-time system.
structure (Listing 6, lines 2-7), declared using the generate keyword. A periodic sensor samples results every d
4.2. Fire Detection Application
seconds for duration k seconds. For instance, a temper-
A home consists of several rooms, each one is instru-
ature sensor generates a tempMeasurement (Listing6, line
mented with several heterogeneous entities for providing
12) of TempStruct type (Listing 6, lines 2-4). It samples
resident’s safety. To ensure the safety of residents, a fire
data every 1 second for next 6 minutes (Listing 6, line
detection application is installed. It aims to detect fire
13). An event-driven sensor produces data when the event
by analyzing data from smoke and temperature sensors.
condition is met. For instance, a smoke sensor generates
When fire occurs, residences are notified on their smart
smokeMeasurement when smokeValue > 650 PPM (Listing
phones by an installed application. Additionally, residents
6, lines 16-17). A set of actuators is declared using the
and their neighbors are informed through a set of alarms
actuators keyword (Listing 6, line 18). Each actuator
as shown in Figure 19.
has one or more actions declared using the action key-
18
Figure 17 – Compilation of deployment spec.
Figure 18 – Packages for target devices specified in the deployment spec.
word. For instance, an Alarm may have one action (e.g, on), illustrated in Listing 6, line 20. 1 2 3
structs : TempStruct
4 5
u n i t O f M e a s u r e m e n t : String ; SmokeStruct
6
smokeValue : double ;
7
u n i t O f M e a s u r e m e n t : String ;
8
tempValue : double ;
19
resources :
9
sensors :
10
per iod icSe nsor s :
11
TemperatureSensor
9
consume r o o m A v g T e m p M e a s u r e m e n t from RoomAvgTemp ;
10
12
generate temp Meas ure ment : TempStruct ;
11
13
sample period 1000 for 6000000;
12
consume sm ok e Me a su r em e nt from SmokeDetector ; generate smokeValue : SmokeStruct ; FireController
14
eventDrivenSensors :
13
consume smokeValue from FireState ;
15
SmokeDetector
14
command On () to Alarm ;
15
command FireNotify ( fireNotify ) to EndUserApp ;
16 17
generate s mo k eM e as u re m en t : SmokeStruct ; onCondition smokeValue > 650 PPM ;
18
actuators :
19
Alarm
20
Listing 7 – A code snippet of architecture spec. Compilation of architecture specification. To compile
action On () ;
architecture specification (arch.mydsl file), Right click on Listing 6 – Code snippet of domain spec.
the arch.mydsl file (Step 1 ) and click on Compile Arch option (Step 2 ) as shown in Figure 14.
Compilation of domain specification. To compile do-
1 2 3 4
main specification (vocab.mydsl file), Right click on the
Import application logic package. To import applica-
vocab.mydsl file (Step 1 ) and click on Compile Vocab
tion logic package, click on File Menu (Step 1 ), and select
option (Step 2 ) as shown in Figure 13.
Import option (Step 2 ) as shown in Figure 15.
Architecture specification. Developer specifies architec-
Locate application logic package. To locate application
ture specification using IoTSuite as shown in Listing 7. It
logic package, browse to Template path (Step 1 ), select
is described as a set of computational services. It consists
application logic package (Step 2 ), and click on Finish
of two types of computational services: (1) Common com-
button (Step 3 ) as shown in Figure 16.
ponent specifies common operations (e.g., average, count,
Implement application logic. The application logic proj-
sum ) in the application logic. For instance, RoomAvgTemp
ect contains a generated framework that hides low-level
component consumes 5 temperature measurements (List-
details from a developer and allows the developer to focus
ing 7, lines 4-5), apply average by sample operation (List-
on the application logic. The developer writes application
ing 7, line 5), and generates roomAvgTempMeasurement
specific logic in logic package. Listing 8 and 9 show gener-
(Listing 7, line 6). (2) Custom component specifies an ap-
ated Java programming framework from the architecture
plication specific logic. Additionally, each computational
specification, defined in Listing 7. To implement appli-
service is described by a set of inputs and outputs. For in-
cation logic of FireState, developers have to implement
stance, the FireController consumes smokeValue (List-
the generated abstract methods illustrated in Listing 8.
ing 7, line 13), issues On and FireNotify (with fireNotify
The FireState component consumes the roomAvgTemp-
as argument) commands (Lines 14-15).
Measurement from RoomAvgTemp, smokeMeasurement from SmokeDetector and generates smokeValue defined in List-
computationalService :
ing 7, lines 9-11. To implement this logic, two methods on-
Common : RoomAvgTemp
NewsmokeMeasurement, and onNewroomAvgTempMeasure-
consume te mpM easu reme nt from T e m p e r a t u r eS e n s o r
ment have to implemented as shown in Listing 8. It reads
; 5
COMPUTE ( AVG_BY_SAMPLE ,5) ;
6
generate r o o m A v g T e m p M e a s u r e m e n t : TempStruct ;
7 8
the smokeMeasurement using onNewsmokeMeasurement method, roomAvgTempMeasurement using onNewroomAvgTe-
Custom :
mpMeasurement method, and setsmokeValue if smokeValue
FireState
and avgtempValue are greater than threshold value. In 20
similar ways, developer implements application logic of
1
FireController component using onNewtempPref method. It issues On command to alarm and fireNotify command
package logic ;
2 3
import java . sql . Timestamp ;
4
import iotsuite . pu b su b mi d dl e wa re . P ub S ub M id d le w ar e
to EndUserApp using onNewsmokeValue method as illustrated in Listing 9 defined in Listing 7 lines 14-15. 1
; 5
import android . content . Context ;
6
import iotsuite . semanticmodel .*;
7
import framework .*;
package logic ;
2 8 3
import iotsuite . pu b su b mi d dl e wa r e . P ub S ub M id d le w ar e 9
public class L o g i c F i r e C o n t r o l l e r extends
; FireController { 4
import android . content . Context ; public L o g i c F i r e C o n t r o l l e r ( Pu b Su b Mi d dl ew a re
10 5
import iotsuite . semanticmodel .*;
6
import framework .*;
pubSubM , Device deviceInfo , Object ui , Context myContext ) {
11 7
super ( pubSubM , deviceInfo ) ;
12 8
public class LogicFireState extends FireState { }
13
double avgtempValue , s m ok e Me a su r em e nt ;
9
14
public LogicFireState ( P ub S ub M id d le w ar e pubSubM ,
10
15
@Override
16
public void on News moke Valu e ( SmokeStruct arg ) {
17
// Read smokeValue from FireState and fire
Device deviceInfo , Object ui , Context myContext ) {
11
super ( pubSubM , deviceInfo ) ;
12
command to Alarm and EndUserApp 13
}
14
@Override
18
On () ;
19
FireNotify ( new Fir eSta teS truc t ( " Fire has been
public void o n N e w s m o k e M e a s u r e m e n t ( SmokeStruct
15
occurred " , arg ) { ( new Timestamp ( new java . util . Date () .
20 16
// Read s mo k eM e as ur e me n t from SmokeDetector
17
s mo k eM e as u re m en t = arg . getsmokeValue () ;
18
// If smokeValue and avgtempValue are greater
getTime () ) ) . toString () ) ) ; }
21 22
than threshold means fire 19
// has been occurred .
20
if ( s mo k eM e as u re m en t > 650 && avgtempValue >
Listing 9 – The implementation of the Java abstract class FireController written by the developer.
55) {
Userinteraction specification. Developer specifies user-
SmokeStruct smokeStruct = new SmokeStruct
21
}
interaction specification using IoTSuite as shown in List-
(650 , " PPM " ) ;
ing 10. It defines what interactions are required by an
setsmokeValue ( smokeStruct ) ;
22
application. We design a set of abstract interactors that
}
23
}
24
denotes data exchange between an application and a user.
25
Notify denotes information flow from an application to a
26
@Override
27
public void o n N e w r o o m A v g T e m p M e a s u r e m e n t (
user. For instance, an application notifies a user in case of fire. It is declared using the notify keyword (Listing
TempStruct arg ) { // Read r o o m A v g T e m p M e a s u r e m e n t from
28
10, line 8). The application notifies users with the fire in-
RoomAvgTemp
2-4).
}
30 31
formation specified in the data structure (Listing 10, lines
avgtempValue = arg . gettempValue () ;
29
}
1
Listing 8 – The implementation of the Java abstract class
2
structs : Fi reSt ateS truc t
FireState written by the developer. 3
21
fireValue : String ;
4 5 6
timeStamp : String ; resources : u se r In t er a ct i on s :
18 19 20
7
EndUserApp
21
8
notify FireNotify ( fireNotify : Fi reSt ateS truc t )
22
from FireController ;
Listing 10 – Code snippet of user-interaction spec. Compilation of userinteraction specification. To com-
23
resources : ; protocol : mqtt ; ResourceMgmtDevice2 : location : Room : 1 ; platform : JavaSE ;
24
resources : ;
25
protocol : mqtt ;
26 27
pile userinteraction specification (userinteraction.mydsl 28
ResourceMgmtDevice3 : location : Room : 1 ;
fil-e), Right click on the userinteraction.mydsl file (Step
29
1 ) and click on Compile UserInteraction option (Step 2 )
30
resources : ;
31
protocol : mqtt ;
as shown in Figure 20.
32
Deployment specification. Developer specifies deployment specification using IoTSuite as shown in Listing 11.
platform : JavaSE ;
EndUserDevice :
33
location :
34
Room :1 ;
It includes properties such as location that defines where
35
platform : Android ;
a device is deployed, resources define component(s) to
36
resources : EndUserApp ;
37
protocol : mqtt ;
be deployed on a device, language-platform is used to Listing 11 – Code snippet of deployment spec.
generate an appropriate package for a device, protocol
1 2
specifies a run-time system in-stalled on a device to inter-
Compilation of deployment spec. Right click on de-
act with other devices. Listing 11 shows a code snippet to
ploy.mydsl file (Step 1 ) and selecting Compile Deploy
illustrate these concepts. SensorMgmtDevice1 is located in
(Step 2 ) as shown in Figure 17 generates a deployment
room#1 (line 4), TemperatureSensor is attached with the
packages.
device (line 6) and the device driver code for this compo-
Import user-interface project. To import user-interface
nent is in NodeJS (line 5), mqtt runtime system is installed
project, click on File Menu (Step 1 ), and select Import
on SensorMgmtDevice1 (line 7).
option (Step 2 ) as shown in Figure 15.
SensorMgmtDevice1 :
3
location :
4
Room :1 ;
5
project, browse to CodeForDeployment folder in Template path (Step 1 ), select project specified in the use-interaction specification (Step 2 ), and click on Finish button (Step
platform : NodeJS ;
6
resources : T e m p e r a t u r e S e n s o r ;
7
protocol : mqtt ;
8
Locate user-interface project. To locate user-interface
devices :
3 ) as shown in Figure 21. Implementing user-interface code. In this step, devel-
SensorMgmtDevice2 :
9
location :
10
Room :1 ;
oper implements user-interface code generated by compilation of user-interaction specification. Developer imple-
11
platform : NodeJS ;
ments user-interface code in deviceImpl package [9, p. 15-
12
resources : SmokeDetector ;
16]. The implementation of user-interface code involves
13
protocol : mqtt ;
14 15 16 17
the use of drag-and-drop functionality provided by form-
ResourceMgmtDevice1 :
widget using activity_main.xml as shown in Figure 22.
location : Room : 1 ;
The developer connects this interaction with generated
platform : JavaSE ;
22
Figure 20 – Compilation of userinteraction spec.
framework in the AndroidEndUserApp.java file. Listing 12 shows how developer connects UI element with gener-
15 16
public A n d r o i d E n d U s e r A p p ( Context context , Lo gicE ndUs erAp p obj ) {
ated framework in deviceImpl package. 1
package deviceImpl ;
2
17
this . appContext = context ;
18
appActivity = ( Activity ) appContext ;
19
pubSubSensingFramework =
20
pubSubSensingFramework . registerForSensorData (
}
3
import logic .*;
4
import framework .*;
5
import android . content . Context ;
6
import android . app . Activity ;
21
7
import iotsuite . android . loca lmid dlew are .
22
IDataListener ; 8
import iotsuite . android . loca lmid dlew are .
P u b S u b s S e n s i n g F r a m e w o r k . getInstance () ;
this , " fi r eN o ti f yN o ti f y " ) ;
23
@Override
24
public void onDataReceived ( String eventName ,
PubSubsSensingFramework ; 9 10
25
// Developer connects UI element with
26
if ( eventName . equals ( " f i re N ot i fy N ot i fy " ) ) {
public class A n d r o i d E n d U s e r A p p implements IEndUserApp , IDataListener {
11
Object data ) {
public static P u b S u b s S e n s i n g F r a m e w o r k
generated framework
Fi reSt ateS truc t fireData = ( Fi reS tate Stru ct
27
pubSubSensingFramework ;
) data ;
12
private Context appContext ;
28
13
public static Activity appActivity ;
29
14
public static String txtDisplay ;
30
23
txtDisplay = fireData . getfireValue () ; } }
Figure 21 – Locate user-interface project
31
in Figure 24.
}
Listing 12 – The implementation of the generated
Specifying Domain specification. Developer specifies
AndroidEndUserApp class written by the developer.
domain specification using IoTSuite as shown in Listing 13. Deployment of generated packages. The output of com-
Each resource is charaterized by types of information it
pilation of deployment specification produce a set of plat-
generates or consumes. A set of information is defined
form specific project/packages as shown in Figure 23 for
using the structs keyword (Listing 13, line 1). A set
devices, specified in the deployment specification (Refer
of sensors is declared using the sensors keyword (Listing
Listing 11). These projects compiled by device specific
13, line 9). Each sensor produces one or more sensor mea-
compiler designed for the target platform. The generated
surements along with the data-types specified in the data
packages integrate the run-time system.
structure (Listing 13, lines 2-7), declared using the generate keyword. A periodic sensor samples results every d
4.3. Smart Home Monitoring Application
seconds for duration k seconds. For instance, a tempera-
A home consists of several rooms, each one is instru-
ture sensor generates a tempMeasurement (Listing 13, line
mented with several heterogeneous entities for providing
12) of TempStruct type (Listing 13, lines 2-4). It samples
resident’s awareness. To provide a resident’s awareness,
data every 1 second for next 6 minutes (Listing 13, line
the system generates the current environment status on
13). A request-based sensor responds its results only if
dashboard (e.g., humidity, temperature, outside tempera-
it is requested. For instance, the YahooWeatherService
ture by interacting with external web services) as shown 24
Figure 22 – Implementation of user-interface code
Figure 23 – Packages for target devices specified in the deployment spec.
provides temperature value of a location given by a locationID (Listing 13, lines 17-19). 1 2 3 4 5
structs : TempStruct tempValue : double ; u n i t O f M e a s u r e m e n t : String ; HumidityStruct
6
humidityValue : double ;
7
u n i t O f M e a s u r e m e n t : String ;
8
resources :
9
sensors :
10 11
per iod icSe nsor s : TemperatureSensor
12
generate temp Meas ure ment : TempStruct ;
13
sample period 1000 for 6000000;
25
count, sum ) in the application logic. (2) Custom specifies an application-specific logic. Additionally, each compu-
DashBoard
tational service is described by a set of inputs and outputs. For instance, the DataVisualizer consumes tempMeasurement, humidityMeasurement, and weatherMeasurement (Listing 14, lines 4-6), issues a DisplaySen-
DataVisualizer
sorMeasurement command with a sensorMeasurement as an argument to Dashboard (line 7). 1 2 3
Yahoo Weather Service
Temperature Sensor
Humidity Sensor
computationalService : Custom : DataVisualizer
4
consume te mpM easu reme nt from
5
consume h u m i d i t y M e a s u r e m e n t from
TemperatureSensor ;
Legend
HumiditySensor ; 6
consume w e a t h e r M e a s u r e m e n t from YahooWeatherService ;
Computational Service
Third-Party Web service
User interface
Sensor
7
command D i s p l a y S e n s o r M e a s u r e m e n t ( s e n s o r M e a s u r e m e n t ) to DashBoard ;
X
Y
X publishes data and Y subscribes
X
Y
X
X commands Y
Y
Listing 14 – A code snippet of architecture spec.
X requests Y, Y replies X
Compilation of architecture specification. To compile architecture specification (arch.mydsl file), Right click on
Figure 24 – Dataflow of Data Visualization Application
the arch.mydsl file (Step 1 ) and click on Compile Arch 14 15 16
Import application logic package. To import applica-
generate h u m i d i t y M e a s u r e m e n t : HumidityStruct ; sample period 1000 for 6000000;
17
requestBasedSensors :
18
YahooWeatherService
19
option (Step 2 ) as shown in Figure 14.
HumiditySensor
tion logic package, click on File Menu (Step 1 ), and select Import option (Step 2 ) as shown in Figure 15. Locate application logic package. To locate application
generate w e a t h e r M e a s u r e m e n t : TempStruct accessed - by locationID : String ;
logic package, browse to Template path (Step 1 ), select
Listing 13 – Code snippet of domain spec.
application logic package (Step 2 ), and click on Finish button (Step 3 ) as shown in Figure 16.
Compilation of domain specification. To compile do-
Implement application logic. The application logic proj-
main specification (vocab.mydsl file), Right click on the
ect contains a generated framework that hides low-level
vocab.mydsl file (Step 1 ) and click on Compile Vocab
details from a developer and allows the developer to focus
option (Step 2 ) as shown in Figure 13.
on the application logic. The developer writes application
Architecture specification. Developer specifies architec-
specific logic in logic package. Listing 15 shows generated
ture specification using IoTSuite as shown in Listing 14.
Java programming framework from the architecture spec-
It is described as a set of computational services. It con-
ification, defined in Listing 14.
sists of two types of computational services: (1) Com-
To implement application logic of DataVisualizer,
mon component specifies common operations (e.g., average, 26
developers have to implement the generated abstract methods illustrated in Listing 15. The DataVisualizer component consumes the tempMeasurement, humidityMeasure-
D i s p l a y S e n s o r M e a s u r e m e n t ( struct ) ;
23
}
24 25
@Override
26
ment, weatherMeasurement and issues DisplaySensorMea- 27
public void o n N e w h u m i d i t y M e a s u r e m e n t (
surement command to Dashboard defined in Listing 14,
HumidityStruct arg ) { // Read h u m i d i t y M e a s u r e m e n t from
lines 4-7. To implement this logic, three methods (onNewwe- 28
HumiditySensor
atherMeasurement, onNewhumidityMeasurement, and on-
humidityValue = arg . g et h um i di t yV al u e () ;
29
NewtempMeasurement) have to implemented as shown in
}
30
Listing 15. It reads tempMeasurement using onNewtemp-
31
Measurement method, humidityMeasurement using on-
32
@Override
33
public void o n N e w t e m p M e a s u r e m e n t ( TempStruct arg
NewhumidityMeasurement method, and weatherMeasurement using onNewweatherMeasurement method illustrated
) { 34
// Read temp Meas urem ent from
35
tempValue = arg . gettempValue () ;
TemperatureSensor
in Listing 15. Additionally, it issues a DisplaySensorMeasurement command to Dashboard using onNewweather-
}
36
Measurement method as shown in Listing 15. 1
37
}
Listing 15 – The implementation of the Java abstract class
package logic ;
DataVisualizer written by the developer. 2 3
import iotsuite . pu b su b mi d dl e wa r e . P ub S ub M id d le w ar e
Userinteraction specification. Developer specifies user-
; 4
import android . content . Context ;
interaction specification using IoTSuite as shown in List-
5
import iotsuite . semanticmodel .*;
ing 16. It defines what interactions are required by an
6
import framework .*;
application. We design a set of abstract interactors that
7 8
denotes data exchange between an application and a user.
public class L o g i c D a t a V i s u a l i z e r extends
Notify denotes information flow from an application to a
DataVisualizer {
user. For instance, an application notifies a user by provid-
9 10
double tempValue , humidityValue ;
ing temperature, humidity and outside temperature value
11 12
13
pubSubM , Device deviceInfo ,
using the notify keyword (Listing 16, line 9). The ap-
Object ui , Context myContext ) {
plication notifies users with the visualization information
super ( pubSubM , deviceInfo ) ;
14 15
by interacting with YahooWeatherService. It is declared
public L o g i c D a t a V i s u a l i z e r ( Pu b Su b Mi dd l ew a re
specified in the data structure (Listing 16, lines 2-5).
} 1
16
structs :
17
@Override
2
VisualizationStruct
18
public void o n N e w w e a t h e r M e a s u r e m e n t ( TempStruct
3
tempValue : double ;
4
humidityValue : double ;
arg ) { 19
// Read w e a t h e r M e a s u r e m e n t from YahooWeatherService
20
// and set D i s p l a y S e n s o r M e a s u r e m e n t to Dashboard
21
V i s u a l i z a t i o n S t r u c t struct = new
5 6 7 8 9
u se r In t er a ct io n s : DashBoard notify D i s p l a y S e n s o r M e a s u r e m e n t ( sensorMeasurement : VisualizationStruct )
V i s u a l i z a t i o n S t r u c t ( tempValue , 22
yahooTempValue : double ; resources :
humidityValue , arg . gettempValue () ) ;
27
Compilation of deployment spec. Right click on de-
from DataVisualizer ;
ploy.mydsl file (Step 1 ) and selecting Compile Deploy
Listing 16 – Code snippet of user-interaction spec.
(Step 2 ) as shown in Figure 17 generates a deployment Compilation of userinteraction specification. To com-
packages.
pile userinteraction specification (userinteraction.mydsl
Import user-interface project. To import user-interface
file), Right click on the userinteraction.mydsl file (Step
project, click on File Menu (Step 1 ), and select Import
1 ) and click on Compile UserInteraction option (Step 2 )
option (Step 2 ) as shown in Figure 15.
as shown in Figure 20.
Locate user-interface project To locate user-interface
Deployment specification. Developer specifies deploy-
project, browse to CodeForDeployment folder in Template
ment specification using IoTSuite as shown in Listing 17.
path (Step 1 ), select project specified in the use-interaction
It includes properties such as location that defines where
specification (Step 2 ), and click on Finish button (Step
a device is deployed, resources define component(s) to
3 ) as shown in Figure 21.
be deployed on a device, language-platform is used to
Implementing user-interface code. In this step, devel-
generate an appropriate package for a device, protocol
oper implements user-interface code generated by compi-
specifies a run-time system installed on a device to inter-
lation of user-interaction specification. Developer imple-
act with other devices. Listing 5 shows a code snippet to
ments user-interface code in deviceImpl package [9, p. 15-
illustrate these concepts. SensorMgmtDevice is located in
16]. To reduce development efforts to implement function-
room#1 (line 4), TemperatureSensor and HumditySensor
ality of Dashboard, we are generating code with default
are attached with the device (line 6) and the device driver
template.
code for these two component is in NodeJS (line 5), mqtt
Deployment of generated packages. The output of com-
runtime system is installed on SensorMgmtDevice (line 7). 1 2 3 4
pilation of deployment specification produce a set of plat-
devices :
form specific project/packages as shown in Figure 25 for
S en s or M gm t De v ic e :
devices, specified in the deployment specification (Refer
location :
Listing 17). These projects compiled by device specific
Room :1 ;
5
platform : NodeJS ;
compiler designed for the target platform. The generated
6
resources : TemperatureSensor , HumiditySensor ;
packages integrate the run-time system.
7
protocol : mqtt ;
8 9 10 11
ResourceMgmtDevice1 :
Room : 1 ;
resources : ;
13
protocol : mqtt
15 16
Since the main goal of this research is to make IoT
platform : JavaSE ;
12
14
5. Conclusion and Future work
location :
application development easy for stakeholders, we believe ;
that our IoT application development process should be
EndUserDevice :
supported by tools to be applicable in an effective way.
location :
Therefore, this paper introduces a design and implemen-
Room :1 ; platform : NodeJS ;
tation of IoTSuite, a suite of tools, for reducing burden of
18
resources : DashBoard ;
each phase of IoT application development process. More-
19
protocol : mqtt ;
17
over, we take different class of IoT applications, largely
Listing 17 – Code snippet of deployment spec.
found in the IoT literature, and demonstrate these IoT 28
Figure 25 – Packages for target devices specified in the deployment spec.
application development using IoTSuite. These applica-
6. Future work
tions have been tested on several IoT technologies such as
This work presents steps involved in IoT application
Android, Raspberry PI, Arduino, and JavaSE-enabled de-
development, and prepares a foundation for our future re-
vices, Messaging protocols such as MQTT, CoAP, Web-
search work. Our future work will proceed in the following
Socket, Server technologies such as Node.js, Relational
complementary directions, discussed below.
database such as MySQL, and Microsoft Azure Cloud serTesting support for IoT application development.
vices.
Our near term future work will be to provide support for
It consists of the following components to aid stake-
the testing phase. A key advantage of testing is that it em-
holders: (1) We integrate a customized editor support for
ulates the execution of an application before deployment
specifying high-level textual specification with the facilities
so as to identify possible conflicts, thus reducing applica-
of syntax coloring and syntax error reporting. (2) A com-
tion debugging effort. The support will be provided by
piler parses the high-level specifications and supports the
integrating an open source simulator in IoTSuite. This
application development phase by producing a program-
simulator will enable transparent testing of IoT applica-
ming framework that reduces development effort. This
tions in a simulated physical environment. Moreover, we
compiler knows at run-time which code generation plug-ins
expect to enable the simulation of a hybrid environment,
are installed and generates code in a target implementa-
combining both real and physical entities. Currently, we
tion language. (3) A deployment module is supported by
are investigating open source simulators for IoT applica-
mapping and linking techniques. They together support
tions. We see Siafu8 as a possible candidate due to its
the deployment phase by producing device-specific code
open source and thorough documentation.
to result in a distributed system collaboratively hosted by
Mapping algorithms cognizant of heterogeneity. We
individual devices. (4) A runtime system leverages ex-
will provide rich abstractions to express both the proper-
isting middleware platforms and generates glue code to
ties of the devices (e.g., processing and storage capacity,
customize them with respect to needs of IoT applications.
networks it is attached to, as well as monetary cost of host-
This mechanism increases the possibility of executing ap-
ing a computational service), as well as the requirements
plications on different middleware.
8 http://siafusimulator.org/
29
from stakeholders regarding the preferred placement of the
URL https://hal.inria.fr/hal-00788366 [12] Patel, P., Kaulgud, V., Chandra, P., Kumar, A., Dec 2015.
computational services of the applications. These will then
Building enterprise-grade internet of things applications. In:
be used to guide the design of algorithms for efficient map-
2015 Asia-Pacific Software Engineering Conference (APSEC).
ping (and possibly migration) of computational services on
pp. 4–5.
devices. *Bibliography
[13] Patel, P., Luo, T., Bellur, U., 2016. Evaluating a development framework for engineering internet of things applications. CoRR abs/1606.02119.
[1] Atzori, L., Iera, A., Morabito, G., 2010. The Internet of Things:
URL http://arxiv.org/abs/1606.02119
A Survey. Computer Networks 54, 2787–2805. [2] Balland, E., Consel, C., N;Kaoua, B., Sauz´ eon, H., 2013. A case
[14] Patel, P., Morin, B., Chaudhary, S., 2014. A model-driven de-
for human-driven software development. In: Proceedings of the
velopment framework for developing sense-compute-control ap-
2013 International Conference on Software Engineering. IEEE
plications. In: Proceedings of the 1st International Workshop
Press.
on Modern Software Engineering Methods for Industrial Au-
URL http://dl.acm.org/citation.cfm?id=2486788.2486970
tomation. MoSEMInA 2014. ACM, New York, NY, USA, pp. 52–61.
[3] Bertran, B., Bruneau, J., Cassou, D., Loriant, N., Balland, E., Consel, C., 2012. DiaSuite: a tool suite to develop sense/com-
[15] Patel, P., Pathak, A., Cassou, D., Issarny, V., Apr. 2013. En-
pute/control applications. Science of Computer Programming.
abling High-Level Application Development in the Internet of
[4] Bischoff, U., Kortuem, G., 2007. Life cycle support for sensor
Things. In: 4th International Conference on Sensor Systems and Software. Lucca, Italy.
network applications. In: Proceedings of the 2nd international
[16] Patel, P., Pathak, A., Teixeira, T., Issarny, V., 2011. Towards
workshop on Middleware for sensor networks. ACM, pp. 1–6.
application development for the Internet of Things. In: Proceed-
[5] Chauhan, S., Patel, P., Delicato, F. C., Chaudhary, S., 2016.
ings of the 8th Middleware Doctoral Symposium. ACM, p. 5.
A development framework for programming cyber-physical sysProceedings of the 2Nd International Workshop
[17] Soukaras, D., Patel, P., Song, H., Chaudhary, S., January 2015.
on Software Engineering for Smart Cyber-Physical Systems.
IoTSuite : A ToolSuite for Prototyping Internet of Things Ap-
SEsCPS ’16. ACM, New York, NY, USA, pp. 47–53.
plications. The 4th International Workshop on Computing and
URL http://doi.acm.org/10.1145/2897035.2897039
Networking for Internet of Things (ComNet-IoT), co-located
tems. In:
with 16th International Conference on Distributed Computing
[6] Chauhan, S., Patel, P., Sureka, A., Delicato, F. C., Chaudhary,
and Networking (ICDCN), 2015.
S., April 2016. Demonstration abstract: Iotsuite - a framework
[18] Taylor, R., Medvidovic, N., Dashofy, E., 2009. Software archi-
to design, implement, and deploy iot applications. In: 2016 15th
tecture: foundations, theory, and practice. Wiley Publishing.
ACM/IEEE International Conference on Information Process-
[19] Vasseur, J.-P., Dunkels, A., 2010. Interconnecting smart objects
ing in Sensor Networks (IPSN). pp. 1–2.
with IP: The next internet. Morgan Kaufmann, San Francisco,
[7] de Saint-Exupery, A., 2009. Internet of things, strategic research
CA, USA.
roadmap. [8] Parr, T., 2007. The definitive ANTLR reference:
Building
domain-specific languages. Pragmatic Bookshelf. [9] Patel, P., Cassou, D., 2015. Enabling high-level application development for the internet of things. Journal of Systems and Software 103, 62 – 84. URL http://www.sciencedirect.com/science/article/pii/ S0164121215000187 [10] Patel, P., Jardosh, S., Chaudhary, S., Ranjan, P., Sept 2009. Context aware middleware architecture for wireless sensor network. In: Services Computing, 2009. SCC ’09. IEEE International Conference on. pp. 532–535. [11] Patel, P., Kattepur, A., Cassou, D., Bouloukakis, G., Feb. 2013. Evaluating the Ease of Application Development for the Internet of Things. Technical report.
30
