Enabling High-Level Application Development for the Internet of Things
EEnabling High-level Application Development for the Internet of Things
Pankesh Patel a , Damien Cassou b a ABB Corporate Research, India b Inria Lille-Nord Europe, France
Abstract
Application development in the Internet of Things (IoT) is challenging because it involves dealing with a wide range ofrelated issues such as lack of separation of concerns, and lack of high-level of abstractions to address both the large scaleand heterogeneity. Moreover, stakeholders involved in the application development have to address issues that can beattributed to different life-cycles phases. when developing applications. First, the application logic has to be analyzedand then separated into a set of distributed tasks for an underlying network. Then, the tasks have to be implementedfor the specific hardware. Apart from handling these issues, they have to deal with other aspects of life-cycle such aschanges in application requirements and deployed devices.Several approaches have been proposed in the closely related fields of wireless sensor network, ubiquitous and pervasivecomputing, and software engineering in general to address the above challenges. However, existing approaches onlycover limited subsets of the above mentioned challenges when applied to the IoT. This paper proposes an integratedapproach for addressing the above mentioned challenges. The main contributions of this paper are: (1) a developmentmethodology that separates IoT application development into different concerns and provides a conceptual frameworkto develop an application, (2) a development framework that implements the development methodology to supportactions of stakeholders. The development framework provides a set of modeling languages to specify each developmentconcern and abstracts the scale and heterogeneity related complexity. It integrates code generation, task-mapping, andlinking techniques to provide automation. Code generation supports the application development phase by producinga programming framework that allows stakeholders to focus on the application logic, while our mapping and linkingtechniques together support the deployment phase by producing device-specific code to result in a distributed systemcollaboratively hosted by individual devices. Our evaluation based on two realistic scenarios shows that the use of ourapproach improves the productivity of stakeholders involved in the application development.
1. Introduction
The recent technological advances have been fueling atremendous growth in a number of smart objects [65, p. 3]such as temperature sensors, smoke detectors, fire alarms,parking space controllers. They can sense the physicalworld by obtaining information from sensors, affect thephysical world by triggering actions using actuators, en-gage users by interacting with them whenever necessary,and process captured data and communicate it to outsideworld. In the
Internet of Things [10], smart objects (or“things”) acquire intelligence thanks to the fact that theycan communicate with each other and cooperate with theirneighbors to reach a common goal [2]. For example, abuilding interacts with its residents and surrounding build-ings in case of fire for safety and security of residents, of-fices adjust themselves automatically accordingly to userpreferences while minimizing energy consumption, or traf-fic signals control in-flow of vehicles according to the cur-rent highway status [55].
Email addresses: [email protected] (PankeshPatel), [email protected] (Damien Cassou)
As evident above, IoT applications will involve inter-actions among large numbers of disparate devices, manyof them directly interacting with their physical surround-ings. An important challenge that needs to be addressedin the IoT, therefore, is to enable the rapid development ofIoT applications with minimal effort by the various stake-holders involved in the process. Similar challenges havealready been addressed in the closely related fields of Wire-less Sensor Networks (WSNs) [65, p. 11] and ubiquitousand pervasive computing [65, p. 7], regarded as precur-sors to the modern day IoT. While the main challenge inthe former is the large scale – hundreds to thousands oflargely similar devices, the primary concern in the latterhas been the heterogeneity of devices and the major rolethat the user’s own interaction with these devices plays inthese systems (cf. the classic “smart home” scenario wherea user controls lights and receives notifications from his re-frigerator and toaster.). It is the goal of our work to enable Throughout this paper, we use the term stakeholders as usedin software engineering to mean – people, who are involved in theapplication development. Examples of stakeholders defined in [63]are software designer, developer, domain expert, technologist, etc.
Preprint submitted to Journal of Systems and Software January 22, 2015 a r X i v : . [ c s . S E ] J a n he development of such applications. In the following, wediscuss one of such applications. We consider a hypothetical building system utilized bya company. This building system might consist of sev-eral buildings, with each building in turn consisting of oneor more floors, each with several rooms. It may consistof a large number of heterogeneous devices equipped withsensors, actuators, storage, user interfaces. Figure 1 de-scribes the building automation domain with various de-vices. Many applications can be developed using thesedevices, one of which we discuss below.
Smart building application.
To accommodate the mo-bile worker’s preference in the reserved room, a database isused to keep the profile of each worker, including his pre-ferred lighting and temperature level. A badge reader inthe room detects the worker’s entry event and queries thedatabase for the worker’s preference. Based on this, thethresholds used by the room’s devices are updated. Toreduce electricity waste when a person leaves the room,detected by badge disappeared event, lighting and heatinglevel are automatically set to the lowest level; all accord-ing to the building’s policy. The system may also includeuser interfaces that allow a late worker to control heaterof his room and request the profile database to get hislighting and temperature preferences. Moreover, the sys-tem generates the current status (e.g., temperature, energyconsumption) of each room, which is then aggregated andused to determine the current status of each floor and,in turn, the entire building. A monitor installed at thebuilding entrance presents the information to the buildingoperator for situational awareness. (1) (1) (1) (1)(1) (1)(2)(3) (1) (1)
Floor (1) (1)(1)(1)
Room (2)(2)
Floor B u il d i ng (4) (5)(6)(6)(6) (7)(7) (9)(10) B u il d i ng B u il d i ng N (8) (8) (8) Figure 1 – A cluster of multi-floored buildings with deployeddevices with (1) temperature sensor, (2) heater, (3) badgereader, (4) badge, (5) alarm, (6) smoke detector, (7) sprinkler,(8) light, (9) data storage, and (10) monitor.
This section reviews the application development chal-lenges as gleaned from our analysis of applications such asthe one discussed in the previous section. The challengeswe address in this work are as follows:
Lack of division of roles . IoT application developmentis a multi-disciplined process where knowledge from mul-tiple concerns intersects. Traditional IoT application de-velopment assumes that the individuals involved in theapplication development have similar skills. This is inclear conflict with the varied set of skills required duringthe process, including domain expertise (e.g., the smartbuilding application reason in terms of rooms and floors,the smart city applications are expressed in terms of sec-tors.), deployment-specific knowledge (e.g., understandingof the specific target area where the application is to bedeployed, mapping of processing components to devices inthe target deployment), application design and implemen-tation knowledge, and platform-specific knowledge (e.g.,Android-specific APIs to get data from sensors, vendor-specific database such as MySQL), a challenge recognizedby recent works such as [14, 51].
Heterogeneity . IoT applications execute on a networkconsisting of heterogeneous devices in terms of types (e.g.,sensing, actuating, storage, and user interface devices), in-teraction modes (e.g. Publish/Subscribe [21], Request/Re-sponse [3], Command [1]), as well as different plat-forms (e.g., Android mobile OS, Java SE on laptops). Theheterogeneity largely spreads into the application code andmakes the portability of code to a different deployment dif-ficult.
Scale . As mentioned above, IoT applications execute ondistributed systems consisting of hundreds to thousands ofdevices, involving the coordination of their activities (e.g.,temperature values are computed at per-room and thenper-floor levels to calculate an average temperature valueof a building). Requiring the ability of reasoning at suchlevels of scale is impractical in general, as has been largelythe view in the WSN community.
Different life cycle phases . Stakeholders have to ad-dress issues that are attributed to different life cyclesphases,including development, deployment, and mainte-nance [7]. At the development phase , the applicationlogic has to be analyzed and separated into a set of dis-tributed tasks for the underlying network consisting of alarge number of heterogeneous entities. Then, the taskshave to be implemented for the specific platform of a de-vice. At the deployment phase , the application logichas to be deployed onto a large number of devices. Apartfrom handling these issues, stakeholders have to keep inmind evolution issues both in the development (change infunctionality of an application such as the smart buildingapplication is extended by including fire detection func-tionality) and deployment phase (e.g. adding/removingdevices in deployment scenarios such as more temperaturesensors are added to sense accurate temperature values in2he building) at the maintenance phase . Manual ef-fort in all above three phases for hundreds to thousands ofheterogeneous devices is a time-consuming and error-proneprocess.In order to address the above mentioned challenges, var-ious approaches have been proposed (for a detailed discus-sion of various systems available for application develop-ment, refer Section 5). One of the approach is node-centricprogramming [66, 54, 16]. It allows for the developmentof extremely efficient systems based on complete controlover individual devices. However, it is not easy to use forIoT applications due to the large size and heterogeneityof systems. In order to address node-centric programminglimitation, various macroprogramming systems [49, 7] havebeen proposed. However, most of macroprogramming sys-tems largely focus on development phase while ignoringthe fact that it represents a tiny fraction of the applica-tion development life-cycle. The lack of a software en-gineering methodology to support the entire applicationdevelopment life-cycle commonly results in highly diffi-cult to maintain, reuse, and platform-dependent design,which can be tackled by the model-driven approach. Toaddress the limitations of macroprogramming systems, ap-proaches based on model-driven design (MDD) have beenproposed [57, 24, 40, 37]. Major benefits came from thebasic idea that by separating different concerns of a systemat a certain level of abstraction, and by providing trans-formation engines to convert these abstractions to a tar-get code, productivity ( e.g. , reusability, maintainability)in the application development process can be improved.
Our aim is to make IoT application development easyfor stakeholders as is the case in software engineering ingeneral, by taking inspiration from the MDD approach andbuilding upon work in sensor network macroprogramming.We achieve this aim by separating IoT application develop-ment into different concerns and integrating a set of high-level languages to specify them. We provide automationtechniques at different phases of IoT application develop-ment to reduce development effort. We now present thesecontributions in detail described below: Development methodology . We propose a developmentmethodology that defines a precise sequence of steps to befollowed to develop IoT applications, thus facilitating IoTapplication development. These steps are separated intofour concerns, namely, domain, functional, deployment,and platform. This separation allows stakeholders to dealwith them individually and reuse them across applications.Each concern is matched with a precise stakeholder accord-ing to skills. The clear identification of expectations and Please note that high-level languages (e.g., AADL, EAST-ADL,SysML, etc.) for IoT have been investigated at length in the do-mains of pervasive/ubiquitous computing and wireless sensor net-work. However, their integration to our development framework inan appropriate way is our contribution. specialized skills of each type of stakeholders helps themto play their part effectively.
Development framework . To support the actions ofeach stakeholder, the development methodology is imple-mented as a concrete development framework . It providesa set of modeling languages, each named after “Srijan”, and offers automation techniques at different phases of IoTapplication development, including the following: • A set of modeling languages . To aid stake-holders, the development framework integrates threemodeling languages that abstract the scale andheterogeneity-related complexity: (1) Srijan Vocabu-lary Language (SVL) to describe domain-specific fea-tures of an IoT application, (2) Srijan ArchitectureLanguage (SAL) to describe application-specific func-tionality of an IoT application, (3) Srijan DeploymentLanguage (SDL) to describe deployment-specific fea-tures consisting information about a physical environ-ment where devices are deployed. • Automation techniques . The development frame-work is supported by code-generation, task-mapping,and linking techniques. These three techniques to-gether provide automation at various phases of IoTapplication development. Code generation supportsthe application development phase by producing aprogramming framework that reduces the effort inspecifying the details of the components of an IoTapplication. Mapping and linking together supportthe deployment phase by producing device-specificcode to result in a distributed system collaborativelyhosted by individual devices.Our work on the above is supported at the lower layersby a middleware that enables delivery of messages acrossphysical regions, thus enabling our abstractions for man-aging large scales in the Internet of Things.
Outline.
The remainder of this paper is organized asfollows: Section 2 presents our development methodologyand its development framework. This includes details of onmodeling languages, automation techniques, and our ap-proach for handling evolutions. Section 3 presents an im-plementation of our development framework. We presenttools, technologies, and programming languages used toimplement this development framework. Section 4 evalu-ates the development framework in a quantitative manner.Section 5 explores state of the art approaches for develop-ing IoT applications. Section 6 summarizes this paper andSection 7 describes briefly some future directions of thiswork. It includes support programs, code libraries, high-level languagesor other software that help stakeholders to develop and glue togetherdifferent components of a software product. Srijan is the sanskrit word for “creation”. . Our approach to IoT application development Applying separation of concerns design principal fromsoftware engineering, we break the identified conceptsand associations among them into different concerns rep-resented in Conceptual model [48], described in Sec-tion 2.1. The identified concepts are linked together intoa well-defined and structured methodology, described inSection 2.2. We implement the proposed developmentmethodology as a concrete development framework [47,46, 61, 45], presented in Section 2.3.
A conceptual model often serves as a base of knowledgeabout a problem area [23]. It represents the concepts aswell as the associations among them and also attempts toclarify the meaning of various terms. Taking inspirationfrom previous efforts [7, 12, 18], we have identified fourmajor concerns for IoT application development. Figure 2illustrates the concepts and their associations along withthese four separate concerns: (1) domain-specific concepts,(2) functionality-specific concepts, (3) deployment-specificconcepts, and (4) platform-specific concepts.
The concepts that fall into this category are specific toa target application domain (e.g., building automation,transport, etc.). For example, the building automationdomain is reasoned in terms of rooms and floors, while thetransport domain is expressed in terms of highway sec-tors. Furthermore, each domain has a set of entities ofinterest (e.g., average temperature of a building, smokepresence in a room), which are observed and controlled bysensors and actuators respectively. Storages store informa-tion about entities of interest, and user interfaces enableusers to interact with entities of interest (e.g., receivingnotification in case of fire in a building, controlling thetemperature of a room). We describe these concepts indetail below: • An Entity of Interest (EoI) is an object (e.g., room,book, plant), including attributes that describe it, andits state that is relevant from a user or an applicationperspective [31, p. 1]. The entity of interest has anobservable property called phenomenon . Typical ex-amples are the temperature value of a room and a tagID. • A resource is a conceptual representation of a sen-sor, an actuator, a storage, or a user interface. Weconsider the following types of resources: – A sensor has the ability to detect changes in theenvironment. Thermometer and tag readers areexamples of sensors. The sensor observes a phe-nomenon of an EoI. For instance, a temperaturesensor observes the temperature phenomenon ofa room. – An actuator makes changes in the environmentthrough an action. Heating or cooling elements,speakers, lights are examples of actuators. Theactuator affects a phenomenon of an EoI by per-forming actions. For instance, a heater is set tocontrol a temperature level of a room. – A storage has the ability of storing data in apersistent manner. The storage stores informa-tion about a phenomenon of an EoI. For instance,a database server stores information about anemployee’s temperature preference. – A user interface represents tasks available tousers to interact with entities of interest. For thebuilding automation domain, a task could be re-ceiving a fire notification in case of emergency orcontrolling a heater according to a temperaturepreference. • A device is located in a region [64]. The region is usedto specify the location of a device. In the buildingautomation domain, a region (or location) of a devicecan be expressed in terms of building, room, and floorIDs.
The concepts that fall into this category describe compu-tational elements of an application and interactions amongthem. A computational element is a type of software com-ponent, which is an architectural entity that (1) encapsu-lates a subset of the system’s functionality and/or data,(2) restricts access to that subset via an explicitly definedinterface [63, p. 69]. We use the term application logic to refer a functionality of a software component. An ex-ample of the application logic is to open a window whenthe average temperature value of a room is greater than ◦ C .The conceptual model contains the followingfunctionality-specific software component, a compu-tational service , which is a type of software componentthat consumes one or more units of information as inputs,processes it, and generates an output. An output could bedata message that is consumed by others or a commandmessage that triggers an action of an actuator. A com-putational service is a representation of the processingelement in an application.A software component communicates-with other soft-ware components to exchange data or control. These in-teractions might contain instances of various interactionmodes such as request-response, publish-subscribe, andcommand. Note that this is in principle an instance ofthe component-port-connector architecture used in soft-ware engineering. The concepts that fall into this category describe infor-mation about devices. Each device hosts zero or more4 bserves AffectsComputational Service StorageStorageServiceDevice Software Component SensorSensorDriver ActuatorDriverActuatorHosts Communicate-withRuns-on Accesses ActuatesEntity of Interest StoresProvides access toResourceLegend:
X extends Y X Y X does Y
Region
X Y X has YX Y * Zero or more Only one
Domain-SpecificConceptsDeployment-Specific Concepts Platform-Specific ConceptsFunctionality-Specific Concepts
End-user application UserInterfaceProvides access toUserusesLocated-in 11.* Interactswith
Figure 2 – Conceptual model for IoT applications resources. For example, a device could host resources suchas a temperature sensor to sense, a heater to control a tem-perature level, a monitor to display a temperature value,a storage to store temperature readings, etc. Each deviceis located-in regions. For instance, a device is located-in room • A device is an entity that provides resources the abil-ity of interacting with other devices. Mobile phones,and personal computers are examples of devices. The concepts that fall into this category are computerprograms that act as a (operating system-specific) trans-lator between a hardware device and an application. Weidentify the following platform-specific concepts: • A sensor driver is a type of software component thatoperates on a sensor attached to a device. It accesses data observed by the sensor and generates the mean-ingful data that can be used by other software com-ponents. For instance, a temperature sensor drivergenerates temperature values and its meta-data such as unit of measurement, time of sensing. Another soft-ware component takes this temperature data as inputand calculates the average temperature of the room. • An actuator driver is a type of software compo-nent that controls an actuator attached to a device.It translates a command from other software compo-nents and actuates the actuator appropriately. Forinstance, a heater driver translates a command “turnthe heater on” to regulate the temperature level. • A storage service is a type of software componentthat provides a read and write access to a storage.A storage service provides access to the storage.Other software components access data from the stor-age by requesting the storage service. For instance,MySQL storage service provides access to a databaseserver. • An end-user application is a type of software com-ponent that is designed to help a user to performtasks (e.g., receiving notifications, submitting infor-mation). It provides access to available tasks. Forinstance, in the smart building application a usercould provide his temperature preferences using an5pplication installed on his smart phone.The next section presents a development methodologythat links the above four concerns and provides a concep-tual framework to develop IoT applications. To make IoT application development easy, stakehold-ers should be provided a structured and well-defined ap-plication development process (referred to as develop-ment methodology ). This section presents a developmentmethodology that integrates different development con-cerns discussed in Section 2.1 and provides a conceptualframework for IoT application development. In additionto this, it assigns a precise role to each stakeholder com-mensurate with his skills and responsibilities.As stated in Section 1.2, IoT application development isa multi-disciplined process where knowledge from multipleconcerns intersects. So far, IoT application developmentassumes that the individuals have similar skills. While thismay be true for simple/small applications for single-usedeployments, as the IoT gains wide acceptance, the needfor sound software engineering approaches to adequatelymanage the development of complex applications arises.Taking inspiration from ideas proposed in the 4+1 viewmodel of software architecture [36], collaboration modelfor smart spaces [14], and tool-based methodology for per-vasive computing [12], we propose a development method-ology that provides a conceptual framework to develop anIoT application (detailed in Figure 3). The developmentmethodology divides the responsibilities of stakeholdersinto five distinct roles —domain expert, software designer,application developer, device developer, and network man-ager. Note that although these roles have been discussed inthe software engineering literature in general, e.g., domainexpert and software designer in [63, p. 657], applicationdeveloper [12, p. 3], their clear identification for IoT appli-cations is largely missing. Due to the existence of various,slightly varying, definitions in literature, we summarizethe skills and responsibilities of the various stakeholdersin Table 1An application corresponds to a specific application do-main (e.g., building automation, health-care, transport)consisting of domain-specific concepts. Keeping this inmind, we separate the domain concern from other con-cerns (see Figure 3, stage 1 ). The main advantage of thisseparation is that domain-specific knowledge can be madeavailable to stakeholders and reused across applications ofa same application domain.IoT applications closely interact with the physical world.Consequently, changes in either of them have a direct in-fluence on the other. The changes could be technologicaladvances with new software features, a change in function-ality of an application, a change in distribution of devices,and adding or replacing devices. Considering this aspect,we separate IoT application development into the plat-form, functional, and deployment concern at the second
Role Skills Responsibilities
Domainexpert Understands domainconcepts, including thedata types produced bythe sensors, consumedby actuators, accessedfrom storages, user’sinteractions, and howthe system is dividedinto regions. Specify the vocabularyof an application do-main to be used byapplications in the do-main.Software de-signer Software architectureconcepts, includingthe proper use of in-teraction modes suchas publish-subscribe,command, and request-response for use in theapplication. Define the structure ofan IoT application byspecifying the softwarecomponents and theirgenerate, consume, andcommand relationships.Applicationdeveloper Skilled in algorithm de-sign and use of pro-gramming languages. Develop the applicationlogic of the computa-tional services in the ap-plication.Device devel-oper Deep understanding ofthe inputs/outputs, andprotocols of the individ-ual devices. Write drivers for thesensors, actuators, stor-ages, and end-user ap-plications used in thedomain.Networkmanager Deep understanding ofthe specific target areawhere the application isto be deployed. Install the applicationon the system at hand;this process may involvethe generation of bina-ries or bytecode, andconfiguring middleware.
Table 1 – Roles in IoT application development stage (see Figure 3, stage 2 ). Thus, stakeholders can dealwith them individually and reuse them across applications.The final stage combines and packs the code generated bythe second stage into packages that be deployed on de-vices (see Figure 3, stage 3 ). To support actions of stakeholders, the developmentmethodology discussed in Section 2.2 is implemented asa concrete development framework. This section presentsthis development framework that provides a set of mod-eling languages, each named after
Srijan , and offers au-tomation techniques at different phases of IoT applicationdevelopment for the respective concerns.
This concern is related to domain-specific concepts of anIoT application. It consists of the following steps: • Specifying domain vocabulary.
The domain ex-pert specifies a domain vocabulary (step 1 in Fig-ure 3) using the Srijan Vocabulary Language (SVL).The vocabulary includes specification of resources,which are responsible for interacting with entities ofinterest. In the vocabulary, resources are specified6 omain expert
Vocabulary
Spec.
Compilation of
Vocabulary
Device
DriverVocabulary
FrameworkDeploymentSpec.NetworkManager MapperArchitectureSpec.
Software
Designer
Compilation of
Architecture
Spec. Architecture
FrameworkApplication logic Linker
Mapping filesApplication Logic,
Architecture
FrameworkDevice Driver,
Vocabulary
Framework
Runtime System
Generated codeFor Device 0Runtime System
Generated code
For Device 1Runtime System
Generated code
For Device NApplication
DeveloperDevice
DeveloperCustomized
ArchitectureGrammer CustomizedArchitecture
Grammer Sensing/Actuating Framework
Domain Concern
Platform
ConcernDeployment ConcernArchitecture Concern
Figure 3 – IoT application development: overall process in a high-level manner to abstract low-level detailsfrom the domain expert. Moreover, the vocabularyincludes definitions of regions that define spatial par-titions (e.g., room, floor, building) of a system. • Compiling vocabulary specification.
Leveragingthe vocabulary, the development framework gener-ates (step 2 in Figure 3): (1) a vocabulary frameworkto aid the device developer, (2) a customized architec-ture grammar according to the vocabulary to aid thesoftware designer, and (3) a customized deploymentgrammar according to the vocabulary to aid the net-work manager. The key advantage of this customiza-tion is that the domain-specific concepts defined inthe vocabulary are made available to other stakehold-ers and can be reused across applications of the sameapplication domain.
This concern is related to functionality-specific conceptsof an IoT application. It consists of the following steps: • Specifying application architecture.
Using a cus-tomized architecture grammar, the software designerspecifies an application architecture (step 3 in Fig-ure 3) using the Srijan Architecture Language (SAL). SAL is an architecture description language (ADL)designed for specifying computational services andtheir interactions with other software components. Tofacilitate scalable operations within IoT applications,SAL offers scope constructs. These constructs allowthe software designer to group devices based on theirspatial relationship to form a cluster (e.g., “devicesare in room • Compiling architecture specification.
The de-velopment framework leverages an architecture speci-fication to support the application developer (step 4in Figure 3). To describe the application logic ofeach computational service, the application developeris provided an architecture framework, pre-configuredaccording to the architecture specification of an ap-plication, an approach similar to the one discussedin [11]. • Implementing application logic.
To describe theapplication logic of each computational service, theapplication developer leverages a generated architec-7ure framework (step 5 in Figure 3). It contains ab-stract classes , corresponding to each computationalservice, that hide interaction details with other soft-ware components and allow the application developerto focus only on application logic. The applicationdeveloper implements only the abstract methods ofgenerated abstract classes. This concern is related to deployment-specific conceptsof an IoT application. It consists of the following steps: • Specifying target deployment.
Using a cus-tomized deployment grammar, the network managerdescribes a deployment specification (step 6 in Fig-ure 3) using the Srijan Deployment Language (SDL).The deployment specification includes the details ofeach device , including its regions (in terms of valuesof the regions defined in the vocabulary), resourceshosted by devices (a subset of those defined in thevocabulary), and the type of the device. Ideally, thesame IoT application could be deployed on differenttarget deployments (e.g., the same inventory trackingapplication can be deployed in different warehouses).This requirement is dictated by separating a deploy-ment specification from other specifications. • Mapping.
The mapper produces a mapping froma set of computational services to a set of de-vices (step 7 in Figure 3). It takes as input a setof placement rules of computational services from anarchitecture specification and a set of devices definedin a deployment specification. The mapper decidesdevices where each computational service will be de-ployed.
This concern is related to platform-specific concepts ofan IoT application. It consists of the following step: • Implementing device drivers.
Leveraging the vo-cabulary, our system generates a vocabulary frame-work to aid the device developer (step 8 in Fig-ure 3). The vocabulary framework contains interfaces and concrete classes corresponding to resources de-fined in the vocabulary. The concrete classes containconcrete methods for interacting with other softwarecomponents and platform-specific device drivers. Theinterfaces are implemented by the device developer towrite platform-specific device drivers. We assume that the application developer uses an object-oriented language. Our work excludes low-end computing devices (e.g., SunSpoT,TelosB, Tmote Sky, etc.). We believe this is a reasonable assump-tion because technological advances in embedded system result intodevices with more and more computational power and memory.
The linker combines and packs code generated by vari-ous stages into packages that can be deployed on devices.It merges generated architecture framework, applicationlogic, mapping files, device drivers, and vocabulary frame-work (step 9 in Figure 3). This stage supports the appli-cation deployment phase by producing device-specific codeto result in a distributed software system collaborativelyhosted by individual devices, thus providing automationat the deployment phase . Evolution is an important aspect in IoT application de-velopment where new resources and computational ser-vices are added, removed, or extended. To deal with thesechanges, our development framework separates IoT appli-cation development into different concerns and allows aniterative development [60] for these concerns.This next section provides the details of our approachincluding three modeling languages (SVL, SAL, and SDL),programming frameworks to aid stakeholders, and an ap-proach for handling evolution. This section refers to thebuilding automation domain discussed in Section 1.1 fordescribing examples.
The domain concern describes an application domain ofan IoT application. The domain expert specifies it usingSVL. A vocabulary includes specification of resources thatare responsible for interacting with entities of interest, in-cluding sensors, actuators, storages, and user interfaces.Moreover, it includes region definitions specific to the ap-plication domain. We now present SVL for describing thedomain concern.SVL is designed to enable the domain expert to describea domain vocabulary domain. It offers constructs to spec-ify concepts that interact with entities of interest. Fig-ure 4 illustrates domain-specific concepts (defined in theconceptual model Figure 2) that can be specified usingSVL. These concepts can be described as V = ( P , D , R ) . P represents the set of regions, D represents the set ofdata structure, and R represents the set of resources. Wedescribe these concepts in detail as follows: regions ( P ). It represents the set of regions that areused to specify locations of devices. A region definitionincludes a region label and region type. For example, thebuilding automation is reasoned in terms of rooms andfloors (considered as region labels), while the transportdomain is expressed in terms of highway sectors. Eachroom or floor in a building may be annotated with aninteger value (e.g. room:1 interprets as room number 1)considered as region type. This construct is declared using We assume that a middleware is already installed on the deployeddevices. The installed middleware enables inter-device communica-tion among devices. egion 1..*VocabularySpecification 1..* 1..* 1..* ** * 1..* 1..*Struct Resource Sensor Actuator Storage User InterfaceAction SensorMeasurement Retrieval Action Command Request 1..* Figure 4 – Class diagram of domain-specific concepts the regions keyword. Listing 1 (lines 1-4) shows regiondefinitions for the building automation domain. data structures ( D ). Each resource is characterized bytypes of information it generates or consumes. A set of in-formation is defined using the structs keyword (Listing 1,line 5). For instance, a temperature sensor may generate atemperature value and unit of measurement (e.g., Celsiusor Fahrenheit). This information is defined as
TempStruct and its two fields (Listing 1, lines 9-11). resources ( R ). It defines resources that might be at-tached with devices, including sensors, actuators, stor-ages, or user interfaces. It is defined as R =( R sensor , R actuator , R storage , R ui ) . R sensor represents aset of sensors, R actuator represents a set of actuators, R storage represents a set of storages, and R ui representsa set of user interfaces. We describe them in detail asfollows: • sensors ( R sensor ) : It defines a set of various typesof sensors (e.g., temperature sensor, smoke detector).A set of sensors is declared using the sensors key-word (Listing 1, line 13). S generate is a set of sen-sor measurements produced by R sensor . Each sen-sor ( S ∈ R sensor ) produces one or more sensor mea-surements ( op ∈ S generate ) along with the data-typesspecified in the data structure ( D ). A sensor measure-ment of each sensor is declared using the generate keyword (Listing 1, line 17). For instance, a temper-ature sensor generates a temperature measurement of Tempstruct type (lines 16-17) defined in data struc-tures (lines 9-11). • actuators ( R actuator ) : It defines a set of varioustypes of actuator (e.g., heater, alarm). A set of actu-ators is declared using the actuators keyword (List-ing 1, line 18). A action is a set of actions performedby R actuator . Each actuator ( A ∈ R actuator ) has oneor more actions ( a ∈ A action ) that is declared using Since a deployment infrastructure may be shared among a num-ber of different IoT applications and users, it is likely that theseapplications may have actuation conflicts. This work assumes actu-ators are pre-configured which can resolve actuation conflicts. the action keyword. An action of an actuator maytake inputs specified as parameters of an action (List-ing 1, line 21). For instance, a heater may has twoactions. One is to switch off the heater and secondis to set the heater according to a user’s temperaturepreference illustrated in Listing 1, lines 19-21. The
SetTemp action takes a user’s temperature preferenceshown in line 21. • storages ( R storage ) : It defines a set of storages (e.g.,user’s profile storage) that might be attached to a de-vice. A set of storages is declared using the stor-ages keyword (Listing 1, line 22). ST generate repre-sents a set of retrievals of R storage . A retrieval ( rq ∈ ST generate ) from the storage ( ST ∈ R storage ) re-quires a parameter. Such a parameter is specifiedusing the accessed-by keyword (Listing 1, line 24).For instance, a user’s profile is accessed from profilestorage by his unique badge identification illustratedin Listing 1, lines 23-24. • user interfaces ( R ui ) : It defines a set of tasks (e.g.,controlling a heater, receiving notification from a firealarm, or requesting preference information from adatabase server) available to users to interact withother entities. A set of user interfaces is declared usingthe user interfaces keyword (Listing 1, line 25).The user interface provides the following tasks: – command ( U command ) : It is a set of commandsavailable to users to control actuators, repre-sented as U command . A user can control an ac-tuator by triggering a command (e.g., switchoff the heater) declared using the command key-word (Listing 1, line 27). – action ( U action ) : It is a set of actions that canbe invoked by other entities to notify users, rep-resented as U action . The other resources may no-tify a user (e.g., notify the current temperature)by invoking an action provided by the user inter-face. The notification task is declared using the action keyword (Listing 1, line 28). – request ( U request ) : It is a set of request thoughwhich a user can request other resources for data,represented as U request . A user can retrieve databy requesting a resource (e.g., retrieve my tem-perature preference). This is declared using the request keyword (Listing 1, line 29). regions : Building : integer ; Even though IoT applications may include rich diverse set ofstorages available today on the Internet ( e.g. , RDBMs and noSQLdatabases, using content that is both user generated such as photosas well as machine generated such as sensor data), we restrict ourwork to key-value data storage services. Floor : integer ; Room : integer ; structs : BadgeDetectedStruct badgeID : string ; timeStamp : long ; TempStruct tempValue : double ; unitOfMeasurement : string ; resources : sensors : BadgeReader generate badgeDetected :BadgeDetectedStruct ; TemperatureSensor generate tempMeasurement : TempStruct ; actuators : Heater action Off (); action SetTemp ( setTemp : TempStruct ); storages : ProfileDB generate profile : TempStructaccessed -by badgeID : string ; userinterfaces : EndUserGUI command Off (); action DisplayData ( displayTemp :TempStruct ); request profile ( badgeID ); Listing 1 – Code snippet of the building automation domainusing SVL. Keywords are printed in blue . The regions ( P ), data structures ( D ), and resources ( R )defined using SVL in the vocabulary are used to customizethe grammar of SAL, and can be exploited by tools toprovide support such as code completion to the softwaredesigner, discussed next. This concern describes computational services and howthey interact with each other to describe functionality ofan application. We describe the computational servicesand interactions among them using SAL (discussed in Sec-tion 2.5.1). The development framework customizes theSAL grammar to make domain-specific knowledge definedin the vocabulary available to the software designer anduse it to generate an architecture framework. The appli-cation developer leverages this generated framework andimplements the application logic on top of it (discussed inSection 2.5.2).
Based on a vocabulary, the SAL grammar is customizedto enable the software designer to design an application.Specifically, sensors ( R sensor ), actuators ( R actuator ), stor-ages ( R storage ), user interfaces ( R ui ), and regions ( P ) de-fined in the vocabulary become possible set of values forcertain attributes in SAL (see underlined words in List-ing 2).Figure 5 illustrates concepts related-to a compu-tational service that can be specified using SAL. It can be described as A v = ( C ) . C represents a setof computational services. It is described as C =( C generate , C consume , C request , C command , C in − region , C hops ) . C generate represents a set of outputs produced bycomputational services. C consume is a set of inputsconsumed by computational services. The inputs couldbe data produced by other computational services orsensors ( R sensor ). C request represents a set of request bycomputational services to retrieve data from the stor-ages ( R storage ). C command represents a set of commandsto invoke actuators ( R actuator ) or user interfaces ( R ui ). C in − region is a set of regions ( R region ) where com-putational services can be placed. C hops is a set ofregions ( R region ) where computational services receivedata. In the following, we describe these concepts indetail. Figure 5 – Class diagram of functionality-specific concepts consume ( C consume ) and generate ( C generate ). Thesetwo concepts together define publish/subscribe interactionmode that provides subscribers with the ability to expresstheir interest in an event, generated by a publisher, thatmatches their registered interest. A computational servicerepresents the publish and subscribe using generate and consume concept respectively. We describe these two con-cepts in details as follows: • consume : It represents a set of subscriptions (or con-sumes) expressed by computational services to getevent notifications generated by sensors ( S generate )defined in the vocabulary specification or other com-putational services ( C generate ) defined in the architec-ture specification. Thus, C consume can be C generate ∪ S generate . A consume ( c ∈ C consume ) of a computa-tional service is expressed using the consume keyword.The computational service expresses its interest by anevent name. For instance, a computational service RoomAvgTemp , which calculates an average tempera-ture of a room, subscribes its interest by expressingevent name tempMeasurement illustrated in Listing 2,line 9.10 generate : It represents a set of publications (or gen-erates) that are produced by computational services.A generate ( g ∈ C generate ) of a computational serviceis expressed using the generate keyword. The com-putational service transforms data to be consumed byother computational services in accordance with theapplication needs. For instance, the computationalservice RoomAvgTemp consumes temperature measure-ments (i.e., tempMeasurement ), calculates an averagetemperature of a room, and generates roomAvgTemp-Measurement (Listing 2, lines 7-9) that is used by
RoomController service (Listing 2, lines 11-12). request ( C request ). It is a set of requests, issued by compu-tational services, to retrieve data from storages ( R storage )defined in the vocabulary specification. A request is aone-to-one synchronous interaction with a return values.In order to fetch data, a requester sends a request mes-sage containing an access parameter to a responder. Theresponder receives and processes the request message, ul-timately returns an appropriate message as a response.An access ( rq ∈ C request ) of the computational service isspecified using request keyword. For instance, a compu-tational service Proximity (Listing 2, line 5), which wantsto access user’s profile data, sends a request message con-taining profile information as an access parameter to astorage
ProfileDB (Listing 1, line 24). command ( C command ). It is a set of commands, issuedby a computational service to trigger actions provided byactuators ( R actuator ) or user interfaces ( R ui ). So, it canbe a subset of A action ∪ U action . The software designercan pass arguments to a command depend on action sig-nature provided by actuators or user interfaces. Moreover,he specifies a scope of command, which specifies a regionwhere commands are issued. A command is specified us-ing the command keyword. An example of command invo-cation is given in line 14 of Listing 2. The room controllerservice (i.e., roomController ), which regulates tempera-ture, issues a SetTemp command with a preferred temper-ature as an argument (i.e., settemp ) to heaters (Listing 1,line 21). in-region ( C in − region ) and hops ( C hops ). To facilitatethe scalable operations within an IoT application, devicesshould be grouped to form a cluster based on their spa-tial relationship [59] (e.g.,“devices are in room
RoomAvgTemp ), deployed in perroom, then later per floor (i.e.,
FloorAvgTemp ), and thenultimately routed to building average temperature service(i.e.,
BuildingAvgTemp ).SAL offers scope constructs to define both the serviceplacement ( C in − region ) and its data interest ( C hops ). Theservice placement (defined using the in-region keyword) Floor
Room
Floor B u il d i ng RoomAvgTemp
FloorAvgTempFloorAvgTempFloorAvgTempBuildingAvgTemp
RoomAvgTemp RoomAvgTemp [1] [1] [1]
Figure 6 – Clustering in the smart building application. Thedevice with temperature sensor is numbered as [1]. is used to govern a placement of computational service ina cluster. The service placement can be in regions definedin a vocabulary specification. So, it is a subset of P .The data interest of a computational service is usedto define a cluster from which the computational servicewants to receive data. The data interest can be in re-gions defined in the vocabulary specification. So, it isa subset of P . It is defined using the hops keyword.The syntax of this keyword is hops:radius:unit of ra-dius . Radius is an integer value. The unit of radius isa cluster value. For example, if a computational service FloorAvgTemp deployed on floor number 12 has a data in-terest hops:i:Floor , then it wants data from all floorsstarting from -th floor to (12+i) -th floor, and all floorsstarting from -th floor to (12-i) -th floor .Figure 7 shows the architecture of the smart buildingapplication. Computational services are fueled by sensingcomponents. They process inputs data and take appropri-ate decisions by triggering actuators. We illustrate SALby examining a code snippet in Listing 2, which describesa part of Figure 7. This code snippet revolves aroundthe actions of the Proximity service (Listing 2, lines 2-6), which coordinates events from the
BadgeReader withthe content of
ProfileDB storage service. To do so, the
Proximity composes information from two sources, onefor badge events (i.e., badge detection), and one for re-questing the user’s temperature profile from
ProfileDB ,expressed using the request keyword (Listing 2, line 5).Input data is declared using the consume keyword thattakes source name and data interest of a computationalservice from logical region (Listing 2, line 4). The decla-ration of hops:0:room indicates that the computationalservice is interested in consuming badge events of the cur-rent room. The
Proximity service is in charge of manag-ing badge events of room. Therefore, we need
Proximity service to be partitioned per room using in-region:room omputationalServiceLegend BadgeReaderBadgeDetectedBadgeDisappearedProximitytempPref Heater off()setTemp() EndUserGUIDisplayData()Storage ActuatorSensor hops:0:Room User interface X X requests Y
YX Y
X commands Y
X Y
X replies Y
X Y
X publishes data and Y subscribes
In-region:Room
RoomControllerOff/SetTemp/offLight/setLight
In-region:Roomhops:0:Room
Light offLight()setLight() hops:0:Roomhops:0:Room
ProfileDBprofile Temperature SensorTempMeasurementRoomAvgTemproomAvgTempMeasurement
In-region:Roomhops:0:Room
FloorAvgTempfloorAvgTemp
In-region:Floorhops:0:Floor
BuildingAvgTempbuildingAvgTemp
In-region:Buildinghops:0:Buildinghops:0:Building
Figure 7 – Architecture of the smart building application,similar to work in [12]. (Listing 2, line 6). The outputs of the
Proximity and
RoomAvgTemp are consumed by the
RoomController ser-vice (Listing 2, lines 11-15). This service is responsiblefor taking decisions that are carried out by invoking com-mands declared using the command keyword (Listing 2,line 14). computationalServices : Proximity generate tempPref : UserTempPrefStruct ; consume badgeDetected from hops :0: Room ; request profile (badgeID ); in - region : Room ; RoomAvgTemp generate roomAvgTempMeasurement : TempStruct ; consume tempMeasurement from hops :0:Room ; in - region : Room ; RoomController consume roomAvgTempMeasurement from hops :0:Room ; consume tempPref from hops :0: Room ; command SetTemp ( setTemp ) to hops :0: Room ; in - region : Room ; Listing 2 – A code snippet of the architecture specificationfor the smart building application using SAL. The languagekeywords are printed in blue , while the keywords derived fromvocabulary are printed underlined.
Leveraging the architecture specification, we generate aframework to aid the application developer. The generated framework contains abstract classes corresponding to thearchitecture specification. The abstract classes include twotypes of methods: (1) concrete methods to interact withother components transparently through the middlewareand (2) abstract methods that allow the application de-veloper to program the application logic. The applicationdeveloper implements each abstract method of generatedabstract class. The key advantage of this framework isthat a framework structure remains uniform. Therefore,the application developer have to know only locations ofabstract methods where they have to specify the applica-tion logic.
Abstract methods.
For each input declared by a com-putational service, an abstract method is generated forreceiving data. This abstract method is then implementedby the application developer. The class diagram in Fig-ure 8 illustrates this concept. This class diagram uses italicized text for the
Proximity class, which representsan abstract class, and onNewbadgeDetected() that rep-resents abstract method. Then, it is implemented in the
SimpleProximity class.Listing 3 and 4 show Java code corresponding to theclass diagram illustrated in Figure 8. From the badgeDe-tected input of the
Proximity declaration in the architec-ture specification (Listing 2, lines 2-6), the onNewbadgeDe-tected() abstract method is generated (Listing 3, line 16).This method is implemented by the application developer.Listing 4 illustrates the implementation of onNewbadgeDe-tected() . It updates a user’s temperature preference andsets it using settempPref() method.
Proximity partitionAttributes : String = "Room"notifyReceived(eventName : String, arg : Object)subscribeBadgeDetected()getProfile(arg : String) onNewbadgeDetected(arg : BadgeDetectedStruct) setTempPref(newValue : userTempPrefStruct)SimpleProximityonNewbadgeDetected(arg : BadgeDetectedStruct)
Figure 8 – Class diagram represents (1) the abstract class
Proximity with its abstract method onNewbadgeDetected() il-lustrated in italicized text, and (2) the concrete implementa-tion of onNewbadgeDetected() method is the
SimpleProximity class. public abstract class Proximity { private String partitionAttribute = " Room "; public void notifyReceived ( String eventName ,Object arg ) { if ( eventName . equals (" badgeDetected ")) { onNewbadgeDetected ((BadgeDetectedStruct ) arg ); } } public void subscribebadgeDetected () { Region regionInfo = getSubscriptionRequest ( partitionAttribute , getRegionLabels () ,getRegionIDs ()); PubSubMiddleware . subscribe (this , "badgeDetected ", regionInfo ); } protected TempStruct getprofile ( String arg ) { return ( TempStruct ) PubSubMiddleware .sendCommand (" getprofile ", arg ,myDeviceInfo ); } protected abstract void onNewbadgeDetected (BadgeDetectedStruct arg ); protected void settempPref ( UserTempPrefStructnewValue ) { if ( tempPref != newValue ) { tempPref = newValue ; PubSubMiddleware . publish (" tempPref ",newValue , myDeviceInfo ); } } } Listing 3 – The Java abstractclass
Proximity generated from the declaration
Proximity inthe architecture specification. public class SimpleProximity extends Proximity { public void onNewbadgeDetected (BadgeDetectedStruct arg ) { long timestamp = (( long ) ( System .currentTimeMillis ())) * 1000000; UserTempPrefStruct userTempPref = newUserTempPrefStruct ( arg . gettempValue () , arg . getunitOfMeasurement (), timestamp ); settempPref ( userTempPref ); } } Listing 4 – The concrete implementation of the Javaabstract class
Proximity from Listing 3, written by theapplication developer.
Concrete methods.
The compilation of an architecturespecification generates concrete methods to interact withother software component transparently. The generatedconcrete methods has the following two advantages:1.
Abstracting heterogeneous interactions.
Toabstract heterogeneous interactions among softwarecomponents, a compiler generates concrete meth-ods that takes care of heterogeneous interactions.For instance, a computational service processes in-put data and produces refined data to its consumers.The input data is either notified by other compo-nent (i.e., publish/subscribe) or requested (i.e., re-quest/response) by the service itself. Then, out-puts are published. The concrete methods for theseinteraction modes are generated in an architectureframework. The lines 2 to 6 of Listing 2 illus-trates these heterogeneous interactions. The
Proxim-ity service has two inputs: (1) It receives badgeDe-tect event (Listing 2, line 4). Our framework gen-erates the subscribebadgeDetected() method to subscribe badgeDetected event (Listing 3, lines 8-12). Moreover, it generates the implementation of notifyReceived() method to receive the publishedevents (Listing 3, lines 3-7). (2) It requests pro-file data (Listing 2, line 5). A sendcommand() method is generated to request data from other com-ponents (Listing 3, lines 13-15).2.
Abstracting large scale.
To address the scalableoperations, a computational service annotates (1) itsinputs with data interest, and (2) its placement in theregion. Service placement and data interest jointlydefine a scope of a computational service to gatherdata. A generated architecture framework containscode that defines both data interest and its place-ment. For example, to get the badgeDetected eventnotification from the
BadgeReader (Listing 2, line 4),the subscribebadgeDetected() method (Listing 3,lines 8-12) is generated in the
Proximity class. Thismethod defines the data interest of a service fromwhere it receives data. The value of partitionAt-tribute (Listing 3, line 2), which comes from thearchitecture specification (Listing 2, line 6), definesthe scope of receiving data. The above constructs areempowered by our choice of middleware, which is avariation of the one presented in [42], and enables de-livery of data across logical scopes.
This concern describes information about a target de-ployment containing various attributes of devices (suchas location, type, attached resources) and locations wherecomputational services are executed in a deployment, de-scribed using SDL (discussed in Section 2.6.1). In orderto map computational services to devices, we present amapping technique that produces a mapping from a setof computational services to a set of devices (discussed inSection 2.6.2).
Figure 9 illustrates deployment-specific concepts (de-fined in the conceptual model Figure 2), specified usingSDL. It includes device properties (such as name, type),regions where devices are placed, and resources that arehosted by devices. The resources ( R ) and regions ( P )defined in a vocabulary become a set of values for cer-tain attributes in SDL (see the underlined words in List-ing 5). SDL can be described as T v = ( D ) . D repre-sents a set of devices. A device ( d ∈ D ) can be definedas ( D region , D resource , D type , D mobile ). D region representsa set of device placements in terms of regions definedin a vocabulary. D resource is a subset of resources de-fined in a vocabulary. D type represents a set of devicetype (e.g., JavaSE device, Android device) that is usedto pick an appropriate device driver from a device driverrepository. D mobile represents a set of two boolean val-ues (true or false). The true value indicates a location of a13evice is not fixed, while the false value shows a fixed loca-tion. Listing 5 illustrates a deployment specification of thesmart building application. This snippet describes a de-vice called TemperatureMgmt-Device-1 with an attached
TemperatureSensor and
Heater , situated in building floor room
1, it is JavaSE enabled and non-mobile de-vice.
Figure 9 – Class diagram of deployment-specific concepts
Note that although individual listing of each device’sattributes appears tedious, i ) we envision that this infor-mation can be extracted from inventory logs that are main-tained for devices purchased and installed in systems, and ii) thanks to the separation between the deployment andfunctional concern in our approach, the same deploymentspecification can be re-used across IoT applications of agiven application domain. devices : TemperatureMgmt - Device -1: region : Building : 15 ; Floor : 11; Room : 1; resources : TemperatureSensor , Heater ; type : JavaSE ; mobile : false ; ... Listing 5 – Code snippet of a deployment specificationfor the building automation domain using SDL. The languagekeywords are printed in blue , while the keywords derived froma vocabulary are printed underlined.
This section presents our mapping algorithm that de-cides devices for a placement of computational services.It takes inputs as (1) a list of devices D defined in a de-ployment specification (see listing 5) and (2) a list of com-putational services C defined in an architecture specifica-tion (see listing 2). It produces a mapping of computa-tional services to a set of devices.We presents the mapping algorithm (see Algorithm 1)that comprises two steps. The first step (lines 4-9) con-structs the two key-value data structures from a deploy-ment specification. These two data structures are used in the second step. The second step (lines 10-20) selects de-vices randomly and allocates computational services to theselected devices . In order to give more clarity to readers,we describes these two steps in detail below.The first step (Algorithm 1, lines 4-9) con-structs two key-value data structures regionM ap and deviceListByRegionV alue from D . The regionM ap (line 6) is a key-value data structure where regionN ame (e.g., Building , Floor , Room in the listing 5)is a key and regionV alue (e.g., , , in the listing 5)is a value. The deviceListByRegionV alue (line 7) isa key-value data structure where regionV alue is a keyand device (e.g., TemperatureMgmt-Device-1 in thelisting 5) is a value. Once, these two data structures areconstructed, we use them for the second step (lines 10-20).The second step (Algorithm 1, lines 10-20) selects adevice and allocates computational services to the se-lected device. To perform this task, the line 10 re-trieves all keys (in our example
Building , Floor , Room ) of regionM ap using getKeySet () function. For each compu-tational service (e.g., Proximity , RoomAvgTemp , RoomCon-troller in listing 2), the selected key from the regionM ap is compared with a partition value of a computationalcomponent (line 12). If the value match, the nextstep (lines 13-17) selects a device randomly and allocatesa computational service to the selected device.
Computational complexity.
The first step (Algo-rithm 1, lines 4-9) takes O ( mr ) times, where m is a numberof devices and r is a number of region pairs in each de-vice specification. The second step (Algorithm 1, lines 10-20) takes O ( nks ) times, where n is a number of regionnames (e.g., building, floor, room for the building automa-tion domain) defined in a vocabulary, k is a number ofcomputational services defined in an architecture specifi-cation, and s is a number of region values specified in adeployment specification. Thus, total computational com-plexity of the mapping algorithm is O ( mr + nks ) . This concern describes software components that act asa translator between a hardware device and an application.Because these components are operating system-specific,the device developer implements them by hand. To aidthe device developer, we generate a vocabulary frameworkto implement platform-specific device drivers. In the fol-lowing section, we describe it in more detail.
Leveraging the vocabulary specification, our system gen-erates a vocabulary framework to aid the device developer.The vocabulary framework contains concrete classes and A mapping algorithm cognizant of heterogeneity, associated withdevices of a target deployment, is a part of our future work. Seefuture work for detail. nput: List D of m numbers of devices, List C of k numbers computational servicesOutput: List mappingOutput of m numbers that containsassignment of C to D
1: Initialize regionMap key-value pair data structure2: Initialize deviceListByRegionV alue key-value pair datastructure3: Initialize mappingOutput key-value pair data structure4: for all device in D do5: for all pairs ( regionName , regionV alue ) in device do6: regionMap [ regionName ] ← regionV alue // construct regionMap with regionName as key and assign regionV alue as Value7: deviceListByRegionV alue [ regionV alue ] ← device
8: end for9: end for10: for all regionName in regionMap.getKeySet () do11: for all computationalservice in C do12: if computationalservice.partitionV alue () = regionName then13: for all regionV alue in regionMap.getV alueSet ( region Name ) do14: deviceList ← deviceListByRegionV alue.getV alueSet ( regionV alue ) selectedDevice ← selectRandomDeviceF romList ( deviceList ) mappingOutput [ selectedDevice ] ← computationalservice
17: end for18: end if19: end for20: end for21: return mappingOutput
Algorithm 1:
Mapping Algorithm interfaces corresponding to resources defined in a vocab-ulary. A concrete class contains concrete methods for in-teracting with other software components and platform-specific device drivers. The interfaces are implementedby the device developer to write platform-specific devicedrivers. In order to enable interactions between concreteclass and platform-specific device driver, we adopt the fac-tory design pattern [25]. This pattern provides an inter-face for a concrete class to obtain an instance of differentplatform-specific device driver implementations withouthaving to know what implementation the concrete class ob-tains. Since the platform-specific device driver implemen-tation can be updated without necessitating any changesin code of concrete class, the factory pattern has advan-tages of encapsulation and code reuse. We illustrate thisconcept in the following paragraph with a
BadgeReader example.The class diagram in Figure 10 illustrates the con-crete class
BadgeReader , the interface
IBadgeReader , andthe associations between them through the factory class
BadgeReaderFactory . The two abstract methods of the
IBadgeReader interface (Listing 8, lines 1-4) are im-plemented in the
AndroidBadgeReader class (Listing 9,lines 1-10). The platform-specific implementation is ac-cessed through the
BadgeReaderFactory class (Listing 7, lines 1-10). The
BadgeReaderFactory class returns an in-stance of platform-specific implementations according torequest by the concrete method registerBadgeReader() in the
BadgeReader class (Listing 6, lines 12-15). In thefollowing, we describe this class diagram with code snip-pet.
Concrete class.
For each resource declared in a vocab-ulary specification, a concrete class is generated. Thisclass contains concrete methods for interacting with othercomponents transparently (similar to discussed in Sec-tion 2.5.2) and for interacting with platform-specific im-plementations. For example, the
BadgeReader (Listing 6,lines 1-16) class is generated from the
BadgeReader dec-laration (Listing 1, lines 14-15). The generated classcontains the registerBadgeReader() method (Listing 6,lines 12-15). This method first obtains a reference ofone (in our example Android) of platform-specific imple-mentations, then uses that reference to create an object ofthat device-specific type (Listing 6, line 13). This refer-ence is used to disseminate badgedetect event (Listing 6,lines 6-11). public class BadgeReader { protected void setbadgeDetected (BadgeDetectedStruct newValue ) { ... PubSubMiddleware . publish (" badgeDetected ",newValue , DeviceInfo ); } badgeDetected badgeDetectEvent = newbadgeDetected () { public void onNewbadgeDetected (BadgeDetectSt resp ) { BadgeDetectSt sBadgeDetectSt = newBadgeDetectSt ( resp . getbadgeID () ,resp . gettimeStamp ()); publishbadgeDetectedEvent (sBadgeDetectSt ); } }; protected void registerBadgeReader (){ IBadgeReader objBadgeReader =BadgeReaderFactory . getBadgeReader ("Android "); objBadgeReader . getbadgeDetected (badgeDetectEvent ); } } Listing 6 – The Java
BadgeReader class generated from the
BadgeReader declaration in the vocabulary specification.
Interfaces.
For each resource declared in a vocabu-lary specification, interfaces are generated. Each interfacecontains synchronous and asynchronous abstract methodscorresponding to a resource declaration. These methodsare implemented by the device developer to write device-specific drivers. For example, our development systemgenerates a vocabulary framework that contains the in-terface
IBadgeReader (Listing 8, lines 1-4) correspond-ing to the
BadgeReader (Listing 1, lines 14-17) declara-tion in the vocabulary specification. The device devel-oper programs Android-specific implementations in the
AndroidBadgeReader class by implementing the methods15 interface»IBadgeReader getbadgeDetected():BadgeDetectedStructgetbadgeDetected (handler : ListenerbadgeDetected)
AndroidBadgeReadergetbadgeDetected():BadgeDetectedStructgetbadgeDetected(handler : ListenerbadgeDetected) BadgeReadersetbadgeDetected(newValue : BadgeDetectedStruct)registerBadgeReader()BadgeReaderFactorygetBadgeReader(BadgeReaderImpl : String) : IBadgeReader
Figure 10 – Class diagram representing (1) the interface
IBadgeReader and the implementation of two abstract methods in the
AndroidBadgeReader class, (2) the concrete class
BadgeReader that refers the
AndroidBadgeReader through the
BadgeReaderFactory factory class. getbadgeDetected() and getbadgeDetected(handler) of the generated interface
IBaderReader (Listing 9, lines 1-10). public class BadgeReaderFactory { public static IBadgeReader getBadgeReader (String nameBadgeReader ) { if( nameBadgeReader . equals (" Android ")) return new AndroidBadgeReader (); if ( nameBadgeReader . equals ("PC")) return new PCBadgeReader (); } } Listing 7 – The Java
BadgeReaderFactory class. public interface IBadgeReader { public BadgeDetectedStruct getbadgeDetected (); public void getbadgeDetected (ListenerbadgeDetected handler ); } Listing 8 – The Java interface
IBadgeReader generated fromthe
BadgeReader declaration in the vocabulary specification. public class AndroidBadgeReader implementsIBadgeReader { @Override public BadgeDetectedStruct getbadgeDetected () { // The device developer implementsplatform - specific code here } @Override public void getbadgeDetected (ListenerbadgeDetected handler ) { // The device developer implementsplatform - specific code here } } Listing 9 – The device developer writes Android-specificdevice driver of a badge reader by implementing the
IBadgeReader interface.
Evolution is an important aspect in IoT application de-velopment where resources and computational services areadded, removed, or extended. To deal with these changes,we separate IoT application development into different concerns and allow an iterative development for these con-cerns. This iterative development requires only a changein evolved specification and reusing dependent specifica-tions/implementation in compilation process, thus reduc-ing effort to handle evolution, similar to the work in [12].Figure 11 illustrates evolution in the functional concern.It could be addition, removal, or extension of computa-tional services. A change in an architecture specificationrequires recompilation of it. The recompilation generatesa new architecture framework and preserves the previouslywritten application logic. This requires changes in the ex-isting application logic implementations manually and re-compilation of the architecture specification to generatenew mapping files that replaces old mapping files. We nowreview main evolution cases in each development concernand how our approach handles them.
Changing functionality . It refers to a change in behav-iors of an application. For example, while an applicationmight be initially defined to switch on an air-conditionerwhen a temperature of room is greater than ◦ C , a newfunctionality might be to open a window. This case re-quires to write a new architecture specification and appli-cation logic. Adding a new computational service . It refers to theaddition of a new computational service in an architecturespecification. The application developer implements theapplication logic of the newly added computational ser-vices.
Removing a computational service . It refers to theremoval of an existing computation service from an ar-chitecture specification. The application developer hasto manually remove application logic files of the removedcomputational service.
Adding a new input source . A new input of a com-putational service, represented as consume keyword, canbe added. The application developer implements a gen-erated abstract method corresponding to a new input inapplication logic files.
Removing a input source . An input can be removedfrom a computational service. In this case, the abstractmethod that implements the application logic becomesdead in application logic files. The IDE automatically re-16 rchitecture spec. ApplicationlogicArchitecture framework Architecture framework Change in architecture spec. ApplicationlogicNewly generated architecture framework ApplicationlogicDeployment spec. Mapper Mappingfiles Mapper New mappingfiles Newly generated architecture frameworkCompilation of architecture spec.Required updates in application logicCompilation of architecture spec.
Figure 11 – Handling evolution in the functional concern ports errors. The application developer has to remove thisdead abstract method manually.
Removing an output or command . An out-put ( generate keyword) or command ( command keyword)can be removed from an architecture specification. In thiscase code, which deals with output or command, becomesdead in application logic files. The application developerhas to manually remove dead code.
3. Components of IoTSuite
In the following, we demonstrate the application de-velopment process, mentioned in Section 2.3, using IoT-Suite – a suite of tools, which is composed of differentcomponents, mentioned below, at each phase of applica-tion development that stakeholders can use. Editor . It helps stakeholders to write high-level specifica-tions, including vocabulary, architecture, and deploymentspecification with the facilities of syntax coloring and syn-tax error reporting. We use Xtext for a full fledged editorsupport, similar to work in [4]. The Xtext is a frame-work for a development of domain-specific languages, andprovides an editor with syntax coloring by writing Xtextgrammar.We take an example of building automation domain vo-cabulary to demonstrate an editor support provided byIoTSuite, illustrated in Figure 12. The zone 1 shows theeditor, where the domain expert writes a domain vocabu-lary. The zone 2 shows the menu bar, where the domainexpert invokes the compiler for vocabulary to generate aframework, a customized architecture grammar, and de-ployment grammar. Compiler . The compiler parses high-level specificationsand translates them into code that can be used by other An open source version, targeting on Android- and JavaSE -enabled devices and MQTT middleware, is available on: https://github.com/pankeshlinux/IoTSuite/wiki components in the system. The parser module of com-piler is implemented using ANTLR , a well-known parsergenerator that creates parser files from grammar descrip-tions. The code generator module of compiler manages arepository of plug-ins. Each plug-in, defined as templatefiles, is specific to a target implementation language (e.g.,Java, Python). The key advantage of it is that it sim-plifies an implementation of a new code generator for atarget implementation. The plug-ins are implemented us-ing StringTemplate Engine, a Java template engine forgenerating source code or any other formatted text out-put. We build two compilers to aid stakeholders shown inFigure 3. (1) compiler for a vocabulary specification, and(2) compiler for an architecture specification. The currentversion of these compilers generate frameworks, compati-ble with Eclipse IDE. Mapper . The mapper produces a mapping from a set ofcomputational services to a set of devices. Figure 13 il-lustrates the architecture of the mapper component. Theparser converts high-level specifications into appropriatedata structures that can be used by a mapping algorithm.The mapping algorithm produces mapping decisions intoappropriate data structures. The code generator consumesthe data structures and generates mapping files. Our cur-rent implementation of the mapper randomly maps com-putational services to a set of devices. However, due togenerality of our architecture, more sophisticated mappingalgorithm can be plugged into the mapper.
Parser Mapping Algorithm Code GeneratorDeployment Spec.Architecture Spec. Mapping files
Mapper
Data structures Mappingdecisions
Figure 13 – Architecture of the mapper component in IoT-Suite.
Linker . It combines and packs code generated by variousstages of compilation into packages that can be deployed ditor area for writing vocabularyspecification Menu bar for invoking compiler Figure 12 – Editor support for writing vocabulary specification in IoTSuite. on devices. The output of the linker is a set of platform-specific projects for devices, specified in the deploymentspecification. These projects are not binaries. They needto be compiled, which can be done by any device-specificcompiler designed for the target platform. The currentversion of the linker generates Java source packages forAndroid and JavaSE platform. Figure 14 illustrates pack-ages for 3 target devices (2 packages for JavaSE devicesand 1 for Android device), which can be imported intoEclipse IDE.
Figure 14 – Packages for target devices compatible withEclipse IDE
Runtime system . The main responsibility of the runtimesystem is a distributed execution of IoT applications. It iscomposed of three parts: (1) middleware : It runs on eachindividual device and provides a support for executing dis-tributed tasks. (2) wrapper : It plugs packages, generatedby the linker module, and middleware. (3) support library :It separates packages, produced by the linker component,and underlying middleware by providing interfaces thatare implemented by each wrapper. The integration of a new middleware into IoTSuite consists of an implementa-tion of the following interfaces, specified by the supportlibrary, in the wrapper. • publish() . It is an interface for publishing data froma sender. The definition of this interface contains: anevent name (e.g., temperature), event data (e.g., atemperature value, Celsius), and publisher’s informa-tion such as location. • subscribe() . It is an interface for receiving eventnotifications. An interest of events is expressed bysending a subscription request, which contains: aevent name (e.g., temperature), information for fil-tering events such as regions of interest (e.g., aRoomAvgTemp component wants to receive eventsonly from a current room), and subscriber’s informa-tion. • command() . It is an interface for triggering an ac-tion of an actuator. A command contains: a com-mand name (e.g., switch-on heater), command param-eters (e.g., set temperature of heater to 30 ◦ C), and asender’s information. • request-response() . It is an interface for requestingdata from a requester. In reply, a receiver sends a re-sponse. A request contains a request name (e.g., giveprofile information), request parameters (e.g., giveprofile of person with identification 12), and informa-tion about the requester.The current implementation of IoTSuite uses the18QTT middleware, which enables interactions amongAndroid devices and JavaSE enabled devices.
4. Evaluation
The goal of this section is to describe how well the pro-posed approach addresses our aim in a quantitative man-ner. Unfortunately, the goal is very vague because qual-ity measures are not well-defined and they do not providea clear procedural method to evaluate development ap-proaches in general. We explore development effort, whichindicates effort required to create an application, that isvital for the productivity of stakeholders [12].To evaluate our approach we consider two representativeIoT applications: (1) the smart building application de-scribed in Section 1.1 and (2) a fire detection application,which aims to detect fire by analyzing data from smokeand temperature sensors. When fire occurs, residences arenotified on their smart phones by an installed application.Additionally, residents of the building and neighborhoodare informed through a set of alarms. Figure 15 showsthe architecture of the fire detection application. A firestate is computed based on a current average temperaturevalue and smoke presence by a local fire state service (i.e., roomFireState ) deployed per room, then a state is sentto a service (i.e., floorFireState ) deployed per floor, andfinally a computational service (i.e., buildingFireCon-troller ) decides whether alarms should be activated andusers should be notified or not.
In order to measure effort to develop an application, weevaluate a percentage of a total number of lines of codegenerated by our approach and effort to develop an ap-plication involving a large number of devices using ourapproach. we have implemented two IoT applications dis-cussed in the previous Section using our approach. Theseapplications are implemented independently. We did notreuse specifications and implementations of one applica-tion in other application. We deployed the two applica-tions on 10 simulated devices running on top of a middle-ware that simulates network on a single PC dedicated tothe evaluation.We measured development effort using EclipseEclEmma 2.2.1 plug-in. This tool counts actual Javastatement as lines of code and does not consider blanklines or lines with comments. Our measurements revealthat more than 82% of the total number of lines of codeis generated in two applications (see Table 2).The measure of lines of code is only useful if the gen-erated code is actually executed. We measured code cov-erage of the generated programming frameworks of twoapplications (see Table 2) using the EclEmma Eclipse http://mqtt.org/ ComputationalServiceLegend SmokeDetectorsmokePresenceAlarmActivate()EndUserGUIGetNotification() ActuatorSensor hops:0:Building
User interface
X Y
X commands Y
X Y
X publishes data and Y subscribes buildingFireController
GetNotification/Activate
In-region: Building
FloorFireStatefloorFireState
In-region: Floor
RoomFireStateroomFireState
In-region: Room
RoomAvgTemp
In-region: Room roomAvgTempMeasurementTemperature SensortempMeasurement hops:0:Buildinghops:0:Buildinghops:0:Floorhops:0:Roomhops:0:Roomhops:0:Room
Figure 15 – Architecture of the fire detection application,similar to work in [12]. plug-in. Our measures show that more than 90% of gen-erated code is actually executed, the other portion beingerror-handling code for errors that did not happen duringthe experiment. This high value indicates that most of theexecution is spent in generated code and that, indeed, ourapproach reduces development effort by generating usefulcode.The above experiment was conducted for 10 simulateddevices. It does not demonstrate development effort usingour approach for a large number of devices. Therefore,the primary aim of this experiment is to evaluate effortto develop an IoT application involving a large numberof devices. In order to achieve the above aim, we havedeveloped the smart building application on a set of sim-ulated device running on top of the middleware dedicatedto the evaluation. The assessments were conducted overan increasing number of devices. The first development ef-fort assessment was conducted on 10 devices instrumentedwith heterogeneous sensors, actuators, storages, and userinterfaces. In the next subsequent assessments, we kept in-creasing the number of devices equipped with sensors andactuators. In each assessment, we have measured lines ofcode to specify vocabulary, architecture, and deployment,application logic, and device drivers. Table 3 illustratesthe assessment results containing a number of devices in-volved in the experiment and hand-written lines of codeto develop the smart building application.In Table 3, we have noted the following two observationsand their reasons:1. As the number of devices increases, lines of code19 andwritten (lines of code) Generated (lines of code) % of Generated code
ApplicationName VocabSpec. Arch.Spec. Deploy.Spec. Devicedriver App.logic Mappingcode Archi.fram. Vocab.fram. generatedhandwritten + generated Code coverage(devices=10)Smart building 41 28 81 98 131 561 408 757 81.99% 92.22Fire detection 27 21 81 53 72 528 292 476 83.61% 90.38
Table 2 – Lines of code in smart building and fire detection applications
Handwritten (lines of code)
Number ofdevices VocabSpec. Arch.Spec. Deploy.Spec. Devicedriver App.logic10 41 28 81 98 13134 41 28 273 98 13150 41 28 401 98 13162 41 28 497 98 13186 41 28 689 98 131110 41 28 881 98 131200 41 28 1601 98 131300 41 28 2401 98 131350 41 28 2801 98 131500 41 28 4001 98 131
Table 3 – Number of devices involved in the developmenteffort assessment and hand-written lines of code to develop thesmart building application. for vocabulary and architecture specification, devicedrivers, and application logic remain constant for a de-ployment consisting a large number of devices. Thereason is that our approach provides the ability tospecify an application at a global level rather thanindividual nodes.2. As the number of devices increases, lines of code for adeployment specification increase. The reason is thatthe network manager specifies each device individu-ally in the deployment specification. This is a limi-tation of SDL. Our future work will be to investigatehow a deployment specification can be expressed ina concise and flexible way for a network with a largenumber of devices. We believe that the use of regu-lar expressions is a possible technique to address thisproblem.
5. Related work
This Section focuses on existing works in literature thatwould address the research challenges discussed in Sec-tion 1.2. As stated earlier, while the application develop-ment life-cycle has been discussed in general in the soft-ware engineering domain, a similar structured approach is largely lacking in the IoT for the development of Sense-Computer-Control (SCC) [63, p. 97] applications. Con-sequently, in this Section we present existing approachesgeared towards the IoT, but also its precursor fields of Per-vasive Computing and Wireless Sensor Networking. Theseare mature fields, with several excellent surveys availableon programming models [62, 43] and middleware [33].We organize this Section based on the perspective ofthe system provided to the stakeholders by the variousapproaches. Section 5.1 presents the node-level program-ming approaches, where the developer has significant con-trol over the actions of each device in the system, whichcomes at the cost of complexity. Section 5.2 summa-rizes approaches that aim to abstract the entire (sens-ing) system as a database on which one can run queries.Section 5.3 presents the evolution of these approaches tomacroprogramming inspired by general-purpose program-ming languages, where abstractions are provided to specifyhigh-level collaborative behaviors at the system-level whilehiding low-level details from stakeholders. Section 5.4then describes the macroprogramming approaches moregrounded in model-driven development techniques, whichaim to provide a cleaner separation of concerns during theapplication development process. We summarize all theseapproaches in Table 4.
In the following, we present systems that adopt thenode-centric approach.In the pervasive computing domain, Olympus [53] isa programming model on top of Gaia [54] – a dis-tributed middleware infrastructure for pervasive environ-ments. Stakeholders write a C++ program that consistsof a high-level description about active space entities (in-cluding service, applications, devices, physical objects, andlocations) and common active operations (e.g., switchingdevices on/, starting/stopping applications). The Olym-pus framework takes care of resolving high-level descrip-tion based on properties specified by stakeholders. Whilethis approach certainly simplifies the SCC application de-velopment involving heterogeneous devices, stakeholdershave to write a lot of code to interface hardware and soft-ware components, as well as to interface software compo-nents and its interactions with a distributed system. Thismakes it tedious to develop applications involving a largenumber of devices.20he Context toolkit [17, 56] simplifies the context-aware application development on top of heterogeneousdata sources by providing three architectural components,namely, widgets, interpreters, and aggregators. Thesecomponents separate application semantics from platform-specific code. For example, an application does not haveto be modified if an Android-specific sensor is used ratherthan a Sun SPOT sensor. It means stakeholders can treata widget in a similar fashion and do not have to deal withdifferences among platform-specific code. Although con-text toolkit provides support for acquiring the context datafrom the heterogeneous sensors, it does not support actu-ation that is an essential part of IoT applications.Henricksen et al. [32, 5] propose a middleware and aprogramming framework to gather, manage, and dissemi-nate context to applications. This work introduces contextmodeling concepts, namely, context modeling languages,situation abstraction; and preference and branching mod-els. This work presents a software engineering process thatcan be used in conjunction with the specified concepts.However, the clear separation of roles among the variousstakeholders is missing. Moreover, this framework limitsitself to context gathering applications, thus not providingthe actuation support that is important for IoT applicationdevelopment.
Physical-Virtual mashup.
As indicated by its name,it connects web services from both the physical and vir-tual world through visual constructs directly from webbrowsers. The embedded device runs tiny web servers [20]to answer HTTP queries from users for checking or chang-ing the state of a device. For instance, users may want tosee temperature of different places on map. Under suchrequirements, stakeholders can use the mashup to connectphysical services such as temperature sensors and virtualservices such as Google map. Many mashup prototypeshave been developed that include both the physical andvirtual services [8, 28, 13, 26, 30]. The mashup editor usu-ally provides visual components representing web serviceand operations (such as add, filter) that stakeholders needto connect together to program an application. The frame-work takes care of resolving these visual components basedon properties specified by stakeholders and produces codeto interface software components and distributed system.The main advantage of this mashup approach is that anyservice, either physical or virtual, can be mashed-up if theyfollow the standards (e.g., REST). The Physical-Virtualmashup significantly lowers the barrier of the applicationdevelopment. However, stakeholders have to manage apotentially large graph for an application involving a largenumber of entities. This makes it difficult to develop ap-plications containing a large number of entities.
In TinyDB [39] and Cougar [68] systems, an SQL-likequery is submitted to a WSN. On receiving a query, thesystem collects data from the individual device, filters it, and sends it to the base station. They provide a suit-able interface for data collection in a network with a largenumber of devices. However, they do not offer much flex-ibility for introducing the application logic. For exam-ple, stakeholders require extensive modifications in theTinyDB parser and query engine to implement new queryoperators.The work on SINA (Sensor Information Networking Ar-chitecture) [59] overcomes this limitation on specificationof custom operators by introducing an imperative languagewith an SQL query. In SINA, stakeholders can embeda script written in Sensor Querying and Tasking Lan-guage (SQTL) [35] in the SQL query. By this hybrid ap-proach, stakeholders can perform more collaborative tasksthan what SQL in TinyDB and Cougar can describe.The TinyDB, Cougar, and SINA systems are largely lim-ited to homogeneous devices. The IrisNet (Internet-ScaleResource-Intensive Sensor Network) [27] allows stakehold-ers to query a large number of distributed heterogeneousdevices. For example, Internet-connected PCs source sen-sor feeds and cooperate to answer queries. Similar to theother database approaches, stakeholders view the sensingnetwork as a single unit that supports a high-level queryin XML. This system provides a suitable interface for datacollection from a large number of different types of de-vices. However, it does not offer flexibility for introducingthe application logic, similar to TinyDB and Cougar.Semantic Streams [67] allows stakeholders to pose adeclarative query over semantic interpretations of sensordata. For example, instead of querying raw magnetome-ter data, stakeholders query whether a vehicle is a car ortruck. The system infers this query and decides sensordata to use to infer the type of vehicle. The main bene-fit of using this system is that it allows people, with lesstechnical background to query the network with heteroge-neous devices. However, it presents a centralized approachfor sensor data collection that limits its applicability forhandling a network with a large number of devices.
Standardized protocols-based systems.
A numberof systems have been proposed to expose functionality ofdevices accessible through standardized protocols withouthaving worry about the heterogeneity of underlying infras-tructure [41]. They logically view sensing devices (e.g., mo-tion sensor, temperature sensor, door and window sensor)as service providers for applications and provide abstrac-tions usually through a set of services. We discuss theseexamples below.Priyantha et al. [52] present an approach based onSOAP [9] to enable an evolutionary WSN where additionaldevices may be added after the initial deployment. To sup-port such a system, this approach has adopted two fea-tures. (1) structured data: the data generated by sensingdevices are represented in a XML format for that may beunderstood by any application. (2) structured function-ality: the functionality of a sensing device is exposed byWeb Service Description Language (WSDL) [15]. While21his system addresses the evolution issue in a target de-ployment, the authors do not demonstrate the evolutionscenarios such as a change in functionality of an applica-tion, technological advances in deployment devices.A number of approaches based on REST [22] have beenproposed to overcome the resource needs and complexityof SOAP-based web services for sensing and actuating de-vices. TinyREST [38] is one of first attempts to overcomethese limitations. It uses the HTTP-based REST architec-ture to access a state of sensing and actuating devices. TheTinyREST gateway maps the HTTP request to TinyOSmessages and allows stakeholders to access sensing andactuating devices from their applications. The aim of thissystem is to make services available through standardizedREST without having to worry about the heterogeneity ofthe underlying infrastructure; that said, it suffers from acentralized structure similar to TinySOA.
In the following, we present macroprogramming lan-guages for IoT application development, which aregrounded in traditional general purpose programming lan-guages (whether imperative or functional) in order to pro-vide developers with familiar abstractions.Kairos [29] allows stakeholders to program an applica-tion in a Python-based language. The Kairos develop-ers write a centralized program of a whole application.Then, the pre-processor divides the program into subpro-grams, and later its compiler compiles it into binary codecontaining code for accessing local and remote variables.Thus, this binary code allows stakeholders to program dis-tributed sensor network applications. Although Kairosmakes the development task easier for stakeholders, it tar-gets homogeneous network where each device executes thesame application.Regiment [44] provides a high-level programming lan-guage based on Haskell to describe an application as a setof spatially distributed data streams. This system pro-vides primitives that facilitate processing data, manipu-lating regions, and aggregating data across regions. Thewritten program is compiled down to an intermediate to-ken machine language that passes information over a span-ning tree constructed across the WSN. In contrast to thedatabase approaches, this approach provides greater flex-ibility to stakeholders when it comes to the applicationlogic. However, the regiment program collects data to asingle base station. It means that the flexibility for any-to-any device collaboration for reducing scale is difficult.MacroLab [34] offers a vector programming abstractionsimilar to Matlab for applications involving both sensingand actuation. Stakeholders write a single program foran entire application using Matlab like operations such as addition , find , and max . The written macroprogram ispassed to the MacroLab decomposer that generates mul-tiple decompositions of the program. Each decompositionis analyzed by the cost analyzer that calculates the cost ofeach decomposition with respect to a cost profile (provided by stakeholders) of a target deployment. After choosing abest decomposition by the cost analyzer, it is passed tothe compiler that converts the decomposition into a bi-nary executable. The main benefit is that it offers flex-ibility of decomposing code according to cost profiles ofthe target platform. While this system certainly separatesthe deployment aspect and functionality of an application,this approach remains general purpose and provides littleguidance to stakeholders about the application domain. A number of model-driven approaches have been pro-posed to make IoT application development easy, de-scribed below.PervML [58] allows stakeholders to specify pervasive ap-plications at a high-level of abstraction using a set of mod-els. This system raises the level of abstraction in programspecification, and code generators produce code from thesespecifications. Nevertheless, it adopts generic UML nota-tions to describe them, thus provides little guidance tostakeholders about the specific application domain. In ad-dition to this, the main focus of this work is to address theheterogeneity associated with pervasive computing appli-cations, and the consideration of a large number of devicesin an application is missing. PervML integrates the map-ping process at the deployment phase. However, stake-holders have to link the application code and configuredevice drivers manually. This manual work in the deploy-ment phase is not suitable for IoT applications involvinga large number of devices. Moreover, the separation be-tween deployment and domain-specific features are miss-ing. These limitations would restrict PervML to a certainlevel.DiaSuite [12] is a suite of tools to develop pervasivecomputing applications. It combines design languages andcovers application development life-cycle. The design lan-guage defines both a taxonomy of an application domainand an application architecture. Stakeholders define enti-ties in a high-level manner to abstract heterogeneity. How-ever, the consideration of a large number of devices in anapplication is largely missing. Moreover, the applicationdeployment for a large number of heterogeneous devices us-ing this approach is difficult because stakeholders requiremanual effort (e.g., mapping of computational services todevices).ATaG [50], which is a WSN is a macroprogrammingframework to develop SCC applications. ATaG presentsa compilation framework that translates a program, con-taining abstract notations, into executable node-level pro-grams. Moreover, it tackles the issue of scale reasonablywell. The ATaG linker and mapper modules support theapplication deployment phase by producing device-specificcode to result in a distributed software system collabo-ratively hosted by individual devices, thus providing au-tomation at deployment phase. Nevertheless, the clearseparation of roles among the various stakeholders in the22pplication development, as well as the focus on hetero-geneity among the constituent devices are largely missing.Moreover, the ATaG program notations remains generalpurpose and provides little guidance to stakeholders aboutthe application domain.RuleCaster [6, 7] introduces an engineering method toprovide support for SCC applications, as well as evolution-ary changes in the application development. The Rule-Caster programming model is based on a logical partition-ing of the network into spatial regions. The RuleCastercompiler takes as input the application program contain-ing rules and a network model that describes device loca-tions and its capabilities. Then, it maps processing tasksto devices. Similar to ATaG, this system handles the scaleissue reasonably well by partitioning the network into sev-eral spatial regions. Moreover, it supports automation atthe deployment phase by mapping computational compo-nents to devices. However, the clear separation of rolesamong the various stakeholders, support for applicationdomain, as well as the focus on heterogeneity among theconstituent devices are missing.Pantagruel [19] is a visual approach dedicated to the de-velopment of home automation applications. The Panta-gruel application development consists of three steps: (1)specification of taxonomy to define entities of the home au-tomation domain (e.g., temperature sensor, alarm, door,smoke detector, etc.), (2) specification of rules to orches-trate these entities using the Pantagruel visual language,and (3) compilation of the taxonomy and orchestrationrules to generate a programming framework. The nov-elty of this approach is that the orchestration rules arecustomized with respect to entities defined in the taxon-omy. While this system reduces the requirement of hav-ing domain-specific knowledge for other stakeholders, theclear separation of different development concerns, supportfor large scale, automation both at the development anddeployment phase are largely missing. These limitationsmake it difficult to use for IoT application development.
6. Conclusion
This paper presents a development methodology for IoTapplication development, based on techniques presentedin the domains of sensor network macroprogramming andmodel-driven development. It separates IoT applicationdevelopment into different concerns and integrates a setof high-level languages to specify them. This approach issupported by automation techniques at different phases ofIoT application development and allows an iterative de-velopment to handle evolutions in different concerns. Ourevaluation based on two realistic IoT applications showsthat our approach generates a significant percentage of thetotal application code, drastically reduces development ef-fort for IoT applications involving a large number of de-vices. Our approach addresses the challenges discussed inSection 1.2 in the following manner:
Lack of division of roles . Our approach identifies rolesof each stakeholder and separates them according to theirskills. The clear identification of expectations and spe-cialized skills of each stakeholder helps them to play theirpart effectively, thus promoting a suitable division of workamong stakeholders involved in IoT application develop-ment.
Heterogeneity . SAL and SVL provide abstractions tospecify different types of devices, as well as heterogeneousinteraction modes in a high-level manner. Further, high-level specifications written using SAL and SVL are com-piled to a programming framework that (1) abstracts het-erogeneous interactions among software components and(2) aids the device developers to write code for differentplatform-specific implementations.
Scale . SAL allows the software designer to express his re-quirements in a compact manner regardless of the scale ofa system. Moreover, it offers scope constructs to facilitatescalable operations within an application. They reducescale by enabling hierarchical clustering in an application.To do so, these constructs group devices to form a clus-ter based on their spatial relationship (e.g., “devices are inroom
Different life cycle phases . Our approach is supportedby code generation, task-mapping, and linking techniques.These techniques together provide automation at differentlife cycle phases. At the development phase, the code gen-erator produces (1) an architecture framework that allowsthe application developer to focus on the application logicby producing code that hide low-level interaction detailsand (2) a vocabulary framework to aid the device devel-oper to implement platform-specific device drivers. At thedeployment phase, the mapping and linking together pro-duce device-specific code to result in a distributed softwaresystem collaboratively hosted by individual devices. Tosupport maintenance phase, our approach separates IoTapplication development into different concerns and allowsan iterative development, supported by the automationtechniques.
7. Future work
This paper addresses the challenges, presented by thesteps involved in IoT application development, and pre-pares a foundation for our future research work. Our fu-ture work will proceed in the following complementary di-rections, discussed below.
Mapping algorithms cognizant of heterogeneity . While the notion of region labels is able to reasonablytackle the issue of scale at an abstraction level, the prob-lem of heterogeneity among the devices still remains. We23 xisting Approaches Division of roles Hetro. Scale Life-cycle phasesDevelopmentphase Deploymentphase MaintenancephaseContextToolkit [17] (2001) × ∼ × × × ∼
Node-centric Olympus [53] (2005) × √ × × × ×
Programming Henricksen et al. [5] (2010) × ∼ × ∼ × ×
Dominique et al. [28] (2010) × √ × ∼ × ∼
TinyDB [39] (2000) × × ∼
Not clear × ×
IrisNet [27] (2000) × ∼ ∼
Not clear × ×
Database SINA [59] (2000) × × √
Not clear × ×
Approach TinyREST [38] (2005) × √ × × × ∼
SemanticStreams [67] (2006) × ∼ × ∼ × ×
Priyantha et al. [52] (2008) × √ × × × ∼
Macroprogramming Kairos [29] (2005) × × √ ∼ ∼ ×
Languages Regiment [44] (2007) × × ∼ ∼ ∼ ×
MacroLab [34] (2008) × × √ ∼ √ ∼
RuleCaster [7] (2007) × × √ ∼ ∼ ∼
Model-driven Pantagruel [19] (2009) ∼ ∼ × ∼ × ∼
Development PervML [58] (2010) ∼ √ × ∼ ∼ ∼
DiaSuite [12] (2011) ∼ √ × √ × ∼
ATaG [50] (2011) × ∼ √ ∼ √ ∼
Table 4 – Comparison of existing approaches. √ – Supported, × – No supported, ∼ – No adequately supported. will provide rich abstractions to express both the proper-ties of the devices (e.g., processing and storage capacity,networks it is attached to, as well as monetary cost of host-ing a computational service), as well as the requirementsfrom stakeholders regarding the preferred placement of thecomputational services of the applications. These will thenbe used to guide the design of algorithms for efficient map-ping (and possibly migration) of computational services ondevices. Developing concise notion for SDL . In the currentversion of SDL, the network manager is forced to spec-ify the detail of each device individually. This approachworks reasonably well in a target deployment with a smallnumber of devices. However, it may be time-consumingand error-prone for a target deployment consisting of hun-dreds to thousands of devices. Our future work will beto investigate how the deployment specification can be ex-pressed in a concise and flexible way for a network with alarge number of device. We believe that the use of regularexpressions is a possible technique to address this problem.
Testing support for IoT application development . Our near term future work will be to provide support forthe testing phase. A key advantage of testing is that it em-ulates the execution of an application before deployment soas to identify possible conflicts, thus reducing applicationdebugging effort. The support will be provided by inte- grating an open source simulator. This simulator will en-able transparent testing of IoT applications in a simulatedphysical environment. Moreover, we expect to enable thesimulation of a hybrid environment, combining both realand physical entities. Currently, we are investigating opensource simulators for IoT applications. We see Siafu asa possible candidate due to its open source and thoroughdocumentation. Run-time adaptation in IoT applications . Eventhough our approach addresses the challenges posed byevolutionary changes in target deployments and appli-cation requirements, stakeholders have to still recompilethe updated code. This is common practice in a singlePC-based development environment, where recompilationis generally necessary to integrate changes. However, itwould be very interesting to investigate how changes canbe injected into the running application that would adaptitself accordingly. For instance, when a new device isadded into the target deployment, an IoT application canautonomously include a new device and assign a task thatcontributes to the execution of the currently running ap-plication. http://siafusimulator.org/ cknowledgment This research work is partially done at University ofParis and French National Institute for Research in Com-puter Science & Automation (INRIA), France duringPankesh Patel’s Ph.D. thesis. The authors would grate-fully like to thank researchers at Inria, Dimitris Soukaras,and the reviewers for their helpful comments and sugges-tions. *References[1] Andrews, G.R., 1991. Paradigms for process interaction in dis-tributed programs. ACM Computing Surveys (CSUR) 23, pp.49–90.[2] Atzori, L., Iera, A., Morabito, G., 2010. The Internet of Things:A Survey. Computer Networks 54, 2787–2805.[3] Berson, A., 1996. Client/server architecture (2. ed.). McGraw-Hill.[4] Bertran, B., Bruneau, J., Cassou, D., Loriant, N., Balland, E.,Consel, C., 2012. DiaSuite: a tool suite to develop sense/com-pute/control applications. Science of Computer Programming.[5] Bettini, C., Brdiczka, O., Henricksen, K., Indulska, J., Nick-las, D., Ranganathan, A., Riboni, D., 2010. A survey of con-text modelling and reasoning techniques. Pervasive and MobileComputing 6, 161–180.[6] Bischoff, U., Kortuem, G., 2006. Rulecaster: A macroprogram-ming system for sensor networks, in: Proceedings OOPSLAWorkshop on Building Software for Sensor Networks.[7] Bischoff, U., Kortuem, G., 2007. Life cycle support for sensornetwork applications, in: Proceedings of the 2nd internationalworkshop on Middleware for sensor networks, ACM. pp. 1–6.[8] Blackstock, M., Lea, R., 2012. WoTKit: a lightweight toolkitfor the web of things, in: Proceedings of the Third InternationalWorkshop on the Web of Things, ACM. p. 3.[9] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendel-sohn, N., Nielsen, H.F., Thatte, S., Winer, D., 2000. Simpleobject access protocol (SOAP) 1.1.[10] CASAGRAS, 2008. RFID and inclusive Model for the Inter-net of Things Available: . Technical Report.EU Framework 7 Project.[11] Cassou, D., Bertran, B., Loriant, N., Consel, C., et al., 2009. Agenerative programming approach to developing pervasive com-puting systems, in: GPCE’09: Proceedings of the 8th interna-tional conference on Generative programming and componentengineering, pp. 137–146.[12] Cassou, D., Bruneau, J., Consel, C., Balland, E., 2011. Towardsa Tool-based Development Methodology for Pervasive Comput-ing Applications. IEEE Transactions on Software Engineering.[13] Castellani, A.P., Dissegna, M., Bui, N., Zorzi, M., 2012. We-bIoT: A web application framework for the internet of things, in:Wireless Communications and Networking Conference Work-shops (WCNCW)” IEEE. pp. 202–207.[14] Chen, C., Helal, S., de Deugd, S., Smith, A., Chang, C.K., 2012.Toward a collaboration model for smart spaces, in: SESENA,pp. 37–42.[15] Chinnici, R., Moreau, J.J., Ryman, A., Weerawarana, S., 2007.Web services description language (WSDL) version 2.0 part 1:Core language. W3C Recommendation 26.[16] Costa, P., Mottola, L., Murphy, A., Picco, G., 2007. Program-ming wireless sensor networks with the teeny lime middleware.Middleware 2007 , 429–449.[17] Dey, A., Abowd, G., Salber, D., 2001. A conceptual frameworkand a toolkit for supporting the rapid prototyping of context-aware applications. Human–Computer Interaction 16, 97–166.[18] Doddapaneni, K., Ever, E., Gemikonakli, O., Malavolta, I.,Mostarda, L., Muccini, H., 2012. A model-driven engineeringframework for architecting and analysing wireless sensor net- works, in: Third International Workshop on Software Engineer-ing for Sensor Network Applications (SESENA), IEEE. pp. 1–7.[19] Drey, Z., Mercadal, J., Consel, C., 2009. A taxonomy-drivenapproach to visually prototyping pervasive computing applica-tions, in: Domain-Specific Languages, Springer. pp. 78–99.[20] Duquennoy, S., Grimaud, G., Vandewalle, J.J., 2009. The Webof Things: interconnecting devices with high usability and per-formance, in: International Conference on Embedded Softwareand Systems (ICESS)., pp. 323–330.[21] Eugster, P., Felber, P., Guerraoui, R., Kermarrec, A., 2003.The many faces of publish/subscribe. ACM Computing Surveys(CSUR) 35, 114–131.[22] Fielding, R.T., 2000. Architectural styles and the design ofnetwork-based software architectures. Ph.D. thesis. Universityof California.[23] Fowler, M., 1996. Analysis Patterns: Reusable Object Models.Addison-Wesley Longman, Amsterdam.[24] France, R., Rumpe, B., 2007. Model-driven development of com-plex software: A research roadmap, in: 2007 Future of SoftwareEngineering, IEEE Computer Society. pp. 37–54.[25] Gamma, E., Helm, R., Johnson, R., Vlissides, J., 1995. De-sign patterns: elements of reusable object-oriented software.Addison-Wesley Longman Publishing Co., Inc.[26] Ghidini, G., Das, S.K., Gupta, V., 2012. Fuseviz: A frameworkfor web-based data fusion and visualization in smart environ-ments, in: IEEE 9th International Conference on Mobile Adhocand Sensor Systems (MASS), IEEE. pp. 468–472.[27] Gibbons, P.B., Karp, B., Ke, Y., Nath, S., Seshan, S., 2003.Irisnet: An architecture for a worldwide sensor web. PervasiveComputing, IEEE 2, 22–33.[28] Guinard, D., Trifa, V., Wilde, E., 2010. A resource orientedarchitecture for the web of things, in: Internet of Things (IOT)”IEEE. pp. 1–8.[29] Gummadi, R., Gnawali, O., Govindan, R., 2005. Macro-programming wireless sensor networks using kairos. DistributedComputing in Sensor Systems , 466–466.[30] Gupta, V., Udupi, P., Poursohi, A., 2010. Early lessons frombuilding sensor. network: an open data exchange for the webof things, in: 8th IEEE International Conference on PervasiveComputing and Communications Workshops, pp. 738–744.[31] Haller, S., 2010. The Things in the Internet of Things. Posterat the (IoT 2010). Tokyo, Japan, November .[32] Henricksen, K., Indulska, J., 2006. Developing context-awarepervasive computing applications: Models and approach. Per-vasive and Mobile Computing 2, 37–64.[33] Henricksen, K., Robinson, R., 2006. A survey of middlewarefor sensor networks: state-of-the-art and future directions, in:Proceedings of the international workshop on Middleware forsensor networks, ACM. pp. 60–65.[34] Hnat, T.W., Sookoor, T.I., Hooimeijer, P., Weimer, W., White-house, K., 2008. Macrolab: a vector-based macroprogrammingframework for cyber-physical systems, in: Proceedings of the6th ACM conference on Embedded network sensor systems,ACM. pp. 225–238.[35] Jaikaeo, C., Srisathapornphat, C., Shen, C.C., 2000. Queryingand tasking in sensor networks, in: AeroSense 2000, Interna-tional Society for Optics and Photonics. pp. 184–194.[36] Kruchten, P., 1995. The 4+ 1 view model of architecture. Soft-ware, IEEE 12, 42–50.[37] Kulkarni, V., Reddy, S., 2003. Separation of concerns in model-driven development. Software, IEEE 20, 64–69.[38] Luckenbach, T., Gober, P., Arbanowski, S., Kotsopoulos, A.,Kim, K., 2005. TinyREST-a protocol for integrating sensornetworks into the internet, in: Proc. of REALWSN, Citeseer.[39] Madden, S., Franklin, M., Hellerstein, J., Hong, W., 2005.TinyDB: An acquisitional query processing system for sensornetworks. ACM Transactions on Database Systems (TODS)30, 122–173.[40] Mellor, S.J., Clark, T., Futagami, T., 2003. Model-driven devel-opment: guest editors’ introduction. IEEE software 20, 14–18.[41] Mohamed, N., Al-Jaroodi, J., 2011. A survey on service-oriented iddleware for wireless sensor networks. Service Oriented Com-puting and Applications 5, 71–85.[42] Mottola, L., Pathak, A., Bakshi, A., Prasanna, V., Picco,G., 2007. Enabling scope-based interactions in sensor networkmacroprogramming, in: Mobile Adhoc and Sensor Systems,2007. MASS 2007. IEEE Internatonal Conference on, IEEE. pp.1–9.[43] Mottola, L., Picco, G., 2011. Programming wireless sensor net-works: Fundamental concepts and state of the art. ACM Com-puting Surveys (CSUR) 43, 19.[44] Newton, R., Morrisett, G., Welsh, M., 2007. The regimentmacroprogramming system, in: Proceedings of the 6th interna-tional conference on Information processing in sensor networks,ACM. pp. 489–498.[45] Patel, P., 2013. Enabling High-Level Application Developmentfor the Internet of Things. These. Universit´e Pierre et MarieCurie - Paris VI. URL: http://tel.archives-ouvertes.fr/tel-00927150/PDF/these.pdf .[46] Patel, P., Morin, B., Chaudhary, S., 2014. A model-driven de-velopment framework for developing sense-compute-control ap-plications, in: Proceedings of the 1st International Workshop onModern Software Engineering Methods for Industrial Automa-tion, ACM, New York, NY, USA. pp. 52–61.[47] Patel, P., Pathak, A., Cassou, D., Issarny, V., 2013. EnablingHigh-Level Application Development in the Internet of Things,in: 4th International Conference on Sensor Systems and Soft-ware, Lucca, Italy.[48] Patel, P., Pathak, A., Teixeira, T., Issarny, V., 2011. Towardsapplication development for the Internet of Things, in: Proceed-ings of the 8th Middleware Doctoral Symposium, ACM. p. 5.[49] Pathak, A., Mottola, L., Bakshi, A., Prasanna, V., Picco, G.,2007. A compilation framework for macroprogramming net-worked sensors. Distributed Computing in Sensor Systems ,189–204.[50] Pathak, A., Prasanna, V., 2011. High-level application develop-ment for sensor networks: Data-driven approach. TheoreticalAspects of Distributed Computing in Sensor Networks , 865–891.[51] Picco, G., 2010. Software engineering and wireless sensor net-works: happy marriage or consensual divorce?, in: Proceedingsof the FSE/SDP workshop on Future of software engineeringresearch, ACM. pp. 283–286.[52] Priyantha, N.B., Kansal, A., Goraczko, M., Zhao, F., 2008.Tiny web services: design and implementation of interoperableand evolvable sensor networks, in: Proceedings of the 6th ACMconference on Embedded network sensor systems, ACM, NewYork, NY, USA. pp. 253–266.[53] Ranganathan, A., Chetan, S., Al-Muhtadi, J., Campbell, R.,Mickunas, M., 2005. Olympus: A high-level programmingmodel for pervasive computing environments, in: Third IEEEInternational Conference on Pervasive Computing and Commu-nications(PerCom)., pp. 7–16.[54] Rom´an, M., Hess, C., Cerqueira, R., Ranganathan, A., Camp-bell, R.H., Nahrstedt, K., 2002. Gaia: a middleware platformfor active spaces. ACM SIGMOBILE Mobile Computing andCommunications Review 6, 65–67.[55] de Saint-Exupery, A., 2009. Internet of things, strategic researchroadmap.[56] Salber, D., Dey, A.K., Abowd, G.D., 1999. The context toolkit:aiding the development of context-enabled applications, in: Pro-ceedings of the SIGCHI conference on Human factors in com-puting systems: the CHI is the limit, ACM, New York, NY,USA. pp. 434–441.[57] Schmidt, D.C., 2006. Guest Editor’s Introduction: Model-Driven Engineering. IEEE Computer Society 39, 25–31. URL: .[58] Serral, E., Valderas, P., Pelechano, V., 2010. Towards the modeldriven development of context-aware pervasive systems. Perva-sive and Mobile Computing 6, 254–280.[59] Shen, C., Srisathapornphat, C., Jaikaeo, C., 2001. Sensor in-formation networking architecture and applications. Personal communications, IEEE 8, 52–59.[60] Sommerville, I., 2010. Software Engineering. 9 ed., Addison-Wesley, Harlow, England.[61] Soukaras, D., Patel, P., Song, H., Chaudhary, S., 2015. IoTSuite: A ToolSuite for Prototyping Internet of Things Applications.The 4th International Workshop on Computing and Network-ing for Internet of Things (ComNet-IoT), co-located with 16thInternational Conference on Distributed Computing and Net-working (ICDCN), 2015 .[62] Sugihara, R., Gupta, R., 2008. Programming models for sensornetworks: A survey. ACM Transactions on Sensor Networks(TOSN) 4, 8.[63] Taylor, R., Medvidovic, N., Dashofy, E., 2009. Software archi-tecture: foundations, theory, and practice. Wiley Publishing.[64] Tubaishat, M., Madria, S., 2003. Sensor networks: an overview.Potentials, IEEE 22, 20–23.[65] Vasseur, J.P., Dunkels, A., 2010. Interconnecting smart objectswith IP: The next internet. Morgan Kaufmann, San Francisco,CA, USA.[66] Whitehouse, K., Sharp, C., Brewer, E., Culler, D., 2004. Hood:a neighborhood abstraction for sensor networks, in: Proceedingsof the 2nd international conference on Mobile systems, applica-tions, and services, ACM. pp. 99–110.[67] Whitehouse, K., Zhao, F., Liu, J., 2006. Semantic streams:a framework for composable semantic interpretation of sensordata, in: Proceedings of the Third European conference onWireless Sensor Networks, Springer-Verlag, Berlin, Heidelberg.pp. 5–20.[68] Yao, Y., Gehrke, J., 2002. The cougar approach to in-networkquery processing in sensor networks. SIGMOD Rec. 31, 9–18..[58] Serral, E., Valderas, P., Pelechano, V., 2010. Towards the modeldriven development of context-aware pervasive systems. Perva-sive and Mobile Computing 6, 254–280.[59] Shen, C., Srisathapornphat, C., Jaikaeo, C., 2001. Sensor in-formation networking architecture and applications. Personal communications, IEEE 8, 52–59.[60] Sommerville, I., 2010. Software Engineering. 9 ed., Addison-Wesley, Harlow, England.[61] Soukaras, D., Patel, P., Song, H., Chaudhary, S., 2015. IoTSuite: A ToolSuite for Prototyping Internet of Things Applications.The 4th International Workshop on Computing and Network-ing for Internet of Things (ComNet-IoT), co-located with 16thInternational Conference on Distributed Computing and Net-working (ICDCN), 2015 .[62] Sugihara, R., Gupta, R., 2008. Programming models for sensornetworks: A survey. ACM Transactions on Sensor Networks(TOSN) 4, 8.[63] Taylor, R., Medvidovic, N., Dashofy, E., 2009. Software archi-tecture: foundations, theory, and practice. Wiley Publishing.[64] Tubaishat, M., Madria, S., 2003. Sensor networks: an overview.Potentials, IEEE 22, 20–23.[65] Vasseur, J.P., Dunkels, A., 2010. Interconnecting smart objectswith IP: The next internet. Morgan Kaufmann, San Francisco,CA, USA.[66] Whitehouse, K., Sharp, C., Brewer, E., Culler, D., 2004. Hood:a neighborhood abstraction for sensor networks, in: Proceedingsof the 2nd international conference on Mobile systems, applica-tions, and services, ACM. pp. 99–110.[67] Whitehouse, K., Zhao, F., Liu, J., 2006. Semantic streams:a framework for composable semantic interpretation of sensordata, in: Proceedings of the Third European conference onWireless Sensor Networks, Springer-Verlag, Berlin, Heidelberg.pp. 5–20.[68] Yao, Y., Gehrke, J., 2002. The cougar approach to in-networkquery processing in sensor networks. SIGMOD Rec. 31, 9–18.