Project topics and materials
Get Complete Project Material File(s) Now! »
Node-centric programming
In this approach, which is most commonly used, stakeholders think in terms of single device activities and explicitly encode its interaction with other devices. For example, they write a program in nesC for TinyOS [Levis et al., 2005] that reads sensing data from appropriate sensing devices, aggregates data pertaining to the some external events, decides where to send it addressed by ID or location, and communicates with actuators if needed. Stakeholders use general-purpose programming language (e.g., Java, C++) and target a particular middleware API or node-level service to develop an application. The node-centric programming makes it possible to develop extremely e cient applications by allowing control over each device. However, due to a large size of the systems, continuous evolution in hardware and software components, and a limited expertise of stakeholders, this approach is not easy to use for IoT application development. In the following, we present systems that adopt the node-centric approach.
In the pervasive computing domain, Olympus [Ranganathan et al., 2005] is a programming model on top of Gaia [Roman et al., 2002] { a distributed middleware infrastructure for pervasive environments. Stakeholders write a C++ program that consists of a high-level description about active space entities (including service, applications, devices, physical objects, and locations) and common active operations (e.g., switching devices on/, starting/stopping applications). The Olympus framework takes care of resolving high-level description based on properties speci ed by stakeholders. While this approach certainly simpli es the SCC application development involving heterogeneous devices, stakeholders have to write a lot of code to interface hardware and software components, as well as to interface software components and its interactions with a distributed system. This makes it tedious to develop applications involving a large number of devices.
The Context toolkit [Dey et al., 2001; Salber et al., 1999] simpli es the context-aware ap-plication development on top of heterogeneous data sources by providing three architectural components, namely, widgets, interpreters, and aggregators. These components separate appli-cation semantics from platform-speci c code. For example, an application does not have to be modi ed if an Android-speci c sensor is used rather than a Sun SPOT sensor. It means stake-holders can treat a widget in a similar fashion and do not have to deal with di erences among platform-speci c code. Although context toolkit provides support for acquiring the context data from the heterogeneous sensors, it does not support actuation that is an essential part of IoT applications.
Henricksen et al. [Bettini et al., 2010; Henricksen and Indulska, 2006] propose a middleware and a programming framework to gather, manage, and disseminate context to applications. This work introduces context modeling concepts, namely, context modeling languages, situation abstraction, and preference and branching models. This work presents a software engineering process that can be used in conjunction with the speci ed concepts. However, the clear separation of roles among the various stakeholders is missing. Moreover, this framework limits itself to context gathering applications, thus not providing the actuation support that is important for IoT application development.
Physical-Virtual mashup. As indicated by its name, it connects web services from both the physical and virtual world through visual constructs directly from web browsers. The embed-ded device runs tiny web servers [Duquennoy et al., 2009] to answer HTTP queries from users for checking or changing the state of a device. For instance, users may want to see tempera-ture of di erent places on map. Under such requirements, stakeholders can use the mashup to connect physical services such as temperature sensors and virtual services such as Google map. Many mashup prototypes have been developed that include both the physical and vir-tual services [Blackstock and Lea, 2012; Castellani et al., 2012; Ghidini et al., 2012; Guinard et al., 2010; Gupta et al., 2010]. The mashup editor usually provides visual components re-presenting web service and operations (such as add, lter) that stakeholders need to connect together to program an application. The framework takes care of resolving these visual com-ponents based on properties speci ed by stakeholders and produces code to interface software components and distributed system. The main advantage of this mashup approach is that any service, either physical or virtual, can be mashed-up if they follow the standards (e.g., REST). The Physical-Virtual mashup signi cantly lowers the barrier of the application development. However, stakeholders have to manage a potentially large graph for an application involving a large number of entities. This makes it di cult to develop applications containing a large number of entities.
Database approach
Since a large part of these systems consists of devices that sense the environment, a natural abstraction for thinking of their functionality at a high level is that of a database, providing access to sensed data. This approach views the whole sensor network as a virtual database system. It provides an easy-to-use interface that lets stakeholders issue queries to a sensor network to extract the data of interest.
In TinyDB [Madden et al., 2005] and Cougar [Yao and Gehrke, 2002] systems, an SQL-like query is submitted to a WSN. On receiving a query, the system collects data from the individual device, lters it, and sends it to the base station. They provide a suitable interface for data collection in a network with a large number of devices. However, they do not o er much exibility for introducing the application logic. For example, stakeholders require extensive modi cations in the TinyDB parser and query engine to implement new query operators. The work on SINA (Sensor Information Networking Architecture) [Shen et al., 2001] over-comes this limitation on speci cation of custom operators by introducing an imperative language with an SQL query. In SINA, stakeholders can embed a script written in Sensor Querying and Tasking Language (SQTL) [Jaikaeo et al., 2000] in the SQL query. By this hybrid approach, stakeholders can perform more collaborative tasks than what SQL in TinyDB and Cougar can describe.
The TinyDB, Cougar, and SINA systems are largely limited to homogeneous devices. The IrisNet (Internet-Scale Resource-Intensive Sensor Network) [Gibbons et al., 2003] allows stake-holders to query a large number of distributed heterogeneous devices. For example, Internet-connected PCs source sensor feeds and cooperate to answer queries. Similar to the other da-tabase approaches, stakeholders view the sensing network as a single unit that supports a high-level query in XML. This system provides a suitable interface for data collection from a large number of di erent types of devices. However, it does not o er exibility for introducing the application logic, similar to TinyDB and Cougar.
Semantic Streams [Whitehouse et al., 2006] allows stakeholders to pose a declarative query over semantic interpretations of sensor data. For example, instead of querying raw magnetome-ter data, stakeholders query whether a vehicle is a car or truck. The system infers this query and decides sensor data to use to infer the type of vehicle. The main bene t of using this system is that it allows people, with less technical background to query the network with heterogeneous devices. However, it presents a centralized approach for sensor data collection that limits its applicability for handling a network with a large number of devices.
A number of systems have been proposed to expose functionality of devices accessible through standardized protocols without having worry about the heterogeneity of underlying infrastructure [Mohamed and Al-Jaroodi, 2001]. They logically view sensing devices (e.g., mo-tion sensor, temperature sensor, door and window sensor) as service providers for applications and provide abstractions usually through a set of services. We discuss these examples below.
TinySOA [Aviles-Lopez and Garc a-Mac as, 2009] is a service-oriented architecture that provides a high-level abstraction for WSN application development. It allows stakeholders to access WSNs using service-oriented APIs provided by a gateway. The APIs provide functions to obtain information about the network, listing devices, and sensing parameters. The gateway component acts as a bridge between a WSN and an application. The gateway consists of a WSN infrastructure registry and discovery components. Through these components, the gate-way allows stakeholders to access data from a WSN without dealing with low-level details. This system provides suitable interfaces from a large number of di erent types of devices for data collection. However, every device in TinySOA is pre-con gured and sends data to the base sta-tion only. Thus, the exibility for in-network processing is limited, similar to TinyDB, Cougar, and IrisNet.
Priyantha et al. [Priyantha et al., 2008] present an approach based on SOAP [Box et al., 2000] to enable an evolutionary WSN where additional devices may be added after the initial deployment. To support such a system, this approach has adopted two features. (1) structured data: the data generated by sensing devices are represented in a XML format for that may be understood by any application. (2) structured functionality: the functionality of a sensing device is exposed by Web Service Description Language (WSDL) [Chinnici et al., 2007]. While this system addresses the evolution issue in a target deployment, the authors do not demons-trate the evolution scenarios such as a change in functionality of an application, technological advances in deployment devices.
A number of approaches based on REST [Fielding, 2000] have been proposed to overcome the resource needs and complexity of SOAP-based web services for sensing and actuating devices. TinyREST [Luckenbach et al., 2005] is one of rst attempts to overcome these limitations. It uses the HTTP-based REST architecture to access a state of sensing and actuating devices. The TinyREST gateway maps the HTTP request to TinyOS messages and allows stakeholders to access sensing and actuating devices from their applications. The aim of this system is to make services available through standardized REST without having to worry about the heterogeneity of the underlying infrastructure; that said, it su ers from a centralized structure similar to TinySOA.
General-purpose macroprogramming languages
To provide a exibility for any-to-any device collaboration (one of limitations of database approach) while preserving global network abstractions, a number of macroprogramming lan-guages have been proposed. They allow stakeholders to specify an application as a global pro-gram, which can then be decomposed into smaller programs that execute on devices. In the following, we present macroprogramming languages for IoT application development, which are grounded in traditional general purpose programming langauges (whether imperative or functional) in order to provide developers with familiar abstractions.
Kairos [Gummadi et al., 2005] allows stakeholders to program an application in a Python-based language. The Kairos developers write a centralized program of a whole application. Then, the pre-processor divides the program into subprograms, and later its compiler compiles it into binary code containing code for accessing local and remote variables. Thus, this binary code allows stakeholders to program distributed sensor network applications. Although Kairos makes the development task easier for stakeholders, it targets homogeneous network where each device executes the same application.
Regiment [Newton et al., 2007] provides a high-level programming language based on Haskell to describe an application as a set of spatially distributed data streams. This system provides primitives that facilitate processing data, manipulating regions, and aggregating data across regions. The written program is compiled down to an intermediate token machine language that passes information over a spanning tree constructed across the WSN. In contrast to the database approaches, this approach provides greater exibility to stakeholders when it comes to the application logic. However, the regiment program collects data to a single base station. It means that the exibility for any-to-any device collaboration for reducing scale is di cult.
MacroLab [Hnat et al., 2008] o ers a vector programming abstraction similar to Matlab for applications involving both sensing and actuation. Stakeholders write a single program for an entire application using Matlab like operations such as addition, find, and max. The written macroprogram is passed to the MacroLab decomposer that generates multiple decompositions of the program. Each decomposition is analyzed by the cost analyzer that calculates the cost of each decomposition with respect to a cost pro le (provided by stakeholders) of a target deploy-ment. After choosing a best decomposition by the cost analyzer, it is passed to the compiler that converts the decomposition into a binary executable. The main bene t is that it o ers exibi-lity of decomposing code according to cost pro les of the target platform. While this system certainly separates the deployment aspect and functionality of an application, this approach remains general purpose and provides little guidance to stakeholders about the application domain.
Model-based macroprogramming
As an evolution of the approaches discussed above which are based on general-purpose programming languages, model-driven approaches to macroprogramming aim to provide greater coverage of the software development lifecycle. They aim to specify an application using high-level abstract models that can be transformed into concrete implementations by automated code generators. A number of model-driven approaches have been proposed to make IoT application development easy level of abstraction using a set of models. This system raises the level of abstraction in program speci cation, and code generators produce code from these speci cations. Nevertheless, it adopts generic UML notations to describe them, thus provides little guidance to stakeholders about the speci c application domain. In addition to this, the main focus of this work is to address the heterogeneity associated with pervasive computing applications, and the consideration of a large number of devices in an application is missing. PervML integrates the mapping process at the deployment phase. However, stakeholders have to link the application code and con gure device drivers manually. This manual work in the deployment phase is not suitable for IoT applications involving a large number of devices. Moreover, the separation between deployment and domain-speci c features are missing. These limitations would restrict PervML to a certain level.
DiaSuite [Cassou et al., 2012] is a suite of tools to develop pervasive computing applications. It combines design languages and covers application development life-cycle. The design language de nes both a taxonomy of an application domain and an application architecture. Stakeholders de ne entities in a high-level manner to abstract heterogeneity. However, the consideration of a large number of devices in an application is largely missing. Moreover, the application deployment for a large number of heterogeneous devices using this approach is di cult because stakeholders require manual e ort (e.g., mapping of computational services to devices).
Our work takes inspiration from ATaG [Pathak and Prasanna, 2011], which is a WSN is a macroprogramming framework to develop SCC applications. The notion of abstract task, abstract data item, and abstract channel are the core of this framework. An abstract task encapsulates the processing of data items. The ow of information among abstract tasks is speci ed in terms of input and output data items. Abstract channels connect abstract tasks to data items. ATaG presents a compilation framework that translates a program, containing abstract notations, into executable node-level programs. Moreover, it tackles the issue of scale reasonably well. The ATaG linker and mapper modules support the application deployment phase by producing device-speci c code to result in a distributed software system collaboratively hosted by individual devices, thus providing automation at deployment phase. Nevertheless, the clear separation of roles among the various stakeholders in the application development, as well as the focus on heterogeneity among the constituent devices are largely missing. Moreover, the ATaG program notations remains general purpose and provides little guidance to stakeholders about the application domain.
RuleCaster [Bischo and Kortuem, 2006, 2007] introduces an engineering method to provide support for SCC applications, as well as evolutionary changes in the application development. The RuleCaster programming model is based on a logical partitioning of the network into spatial regions. Each region is in one discrete state. A rule-based language is used to specify a transition of the state, where each rule consists of two parts : (1) body and (2) head. The body part speci es a re condition, and the head part speci es one or more actions when the condition becomes true. The RuleCaster compiler takes as input the application program containing rules and a network model that describes device locations and its capabilities. Then, it maps processing tasks to devices. Similar to ATaG, this system handles the scale issue reasonably well by partitioning the network into several spatial regions. Moreover, it supports automation at the deployment phase by mapping computational components to devices. However, the clear separation of roles among the various stakeholders, support for application domain, as well as the focus on heterogeneity among the constituent devices are missing.
Pantagruel [Drey et al., 2009] is a visual approach dedicated to the development of home automation applications. The Pantagruel application development consists of three steps: (1) speci cation of taxonomy to de ne entities of the home automation domain (e.g., temperature sensor, alarm, door, smoke detector, etc.), (2) speci cation of rules to orchestrate these entities using the Pantagruel visual language, and (3) compilation of the taxonomy and orchestration rules to generate a programming framework. The novelty of this approach is that the orchestra-tion rules are customized with respect to entities de ned in the taxonomy. While this system reduces the requirement of having domain-speci c knowledge for other stakeholders, the clear separation of di erent development concerns, support for large scale, automation both at the development and deployment phase are largely missing. These limitations make it di cult to use for IoT application development.
Chapter summary and conclusion
This chapter has investigated existing works for IoT application development. Table II.1 √ compares approaches with respect to the challenges discussed in Chapter I. The symbol \ » means the challenge is supported by the approach, \× » means \not supported », and \∼ » means \no adequately supported ». Due to similarity, we pick one representative system in some cases. For instance, TinyDB and Cougar have adopted SQL-based interface for collecting data. So, we take only TinyDB as a representative example.
As illustrated in Table II.1, our investigation has revealed that many ideas have been propo-sed for addressing the research challenges individually. However, none of the examined approach addresses all of the identi ed challenges to a su cient extent. More speci cally, we note the following observations based on our literature survey: Division of roles. Most of the application development approaches do not divide roles of stakeholders to a su cient extent. This is in clear con ict with the varied set of skills required during IoT application development, including domain expertise, deployment-speci c know-ledge, application design and implementation skill, and ability to deal with operating system and hardware-speci c details. The clear identi cation of expectations and specialized skills of each type of stakeholder is necessary to play their part e ectively to smoothen the application development.
Heterogeneity and Scale. Existing approaches address the scale and heterogeneity challenge, but individually. None of the examined approach addresses these two challenges to a su cient extend. IoT applications are heterogeneous in terms of device types, interaction modes, and dif-ferent implementations. Moreover than this, they may execute on systems consists of hundreds to thousands of devices. Therefore, it is important to address both the issues in one approach.
General purpose modeling languages. Some approaches customize modeling languages with respect to an application domain. However, most of approaches remain general purpose (e.g., a modeling language proposed by PervML relies on generic UML notations), thus provide little guidance to stakeholders about the application domain. The key advantage of the custo-mization is that domain-speci c knowledge is made available to stakeholders and can be reused across applications of the same application domain, and thus the \one-size- ts-all » approach needs to be revisited for IoT application development.
Evolution. An IoT application may involve a number of changes such as technological advances with new software features and changes in a distribution of devices in a target deployment, deployment of the same application on a di erent deployment, changes in functionality of an application. Existing approaches do not address these evolutionary changes to a su cient extent. Therefore, it is necessary to consider them comprehensively for IoT application development.
Automation at development phase. IoT applications involve a large number of heteroge-neous devices. Consequently, stakeholders face the prospect of spending a lot of time in manual e ort that is attributed to the development and deployment phases of the application develop-ment. While some approaches address poor automation problem at development phase to allow stakeholders to focus on the application logic, they do not address automation at deployment phase to a su cient extend. Therefore, automation at both the deployment and development phase remains missing in the existing approaches.
In conclusion, there is a need of designing a new approach that utilizes advantages and promising features of the existing works to develop a comprehensive integrated approach while focusing on ease of IoT application development.
Table of contents :
I Introduction
1 Application example
2 IoT application characteristics
3 IoT application development challenges
4 Application development approaches
4.1 Node-centric and Macro-programming
4.2 Model-driven development
5 Aim of thesis
6 Thesis contributions
7 Thesis structure
II Related work
1 Node-centric programming
2 Database approach
3 General-purpose macroprogramming languages
4 Model-based macroprogramming
5 Chapter summary and conclusion
III Our approach to IoT application development
1 Overview
1.1 Conceptual model
1.1.1 Domain-specic concepts
1.1.2 Functionality-specic concepts
1.1.3 Deployment-specic concepts
1.1.4 Platform-specic concepts
1.2 A development methodology for IoT applications
2 Multi-step IoT application development process
2.1 Overview
2.1.1 Domain concern
2.1.2 Functional concern
2.1.3 Deployment concern
2.1.4 Platform concern
2.1.5 Linking
2.1.6 Handling evolution
2.2 Specifying domain concern with the Srijan vocabulary language (SVL)
2.3 Specifying functional concern
2.3.1 Srijan architecture language (SAL)
2.3.2 Implementing application logic
2.4 Specifying deployment concern
2.4.1 Srijan deployment language (SDL)
2.4.2 Mapping
2.5 Specifying platform concern
2.5.1 Implementing device drivers
2.6 Handling evolution
2.6.1 Evolution in functional concern
2.6.2 Evolution in deployment concern
2.6.3 Evolution in platform concern
2.6.4 Evolution in domain concern
3 Chapter summary
IV SrijanSuite: implementation of our approach
1 System overview
2 System components
2.1 Editor
2.2 Compiler
2.3 Mapper
2.4 Linker
2.5 Runtime system
3 Eclipse plug-in
4 Chapter summary
V Evaluation 73
1 Evaluation metrics
2 Applications for evaluation
3 Development eort
4 Reusability
4.1 Change in target deployment
4.2 Evolution in functionality
5 Code quality
5.1 Code coverage
5.2 Cyclomatic complexity
6 Chapter summary
VI Conclusion and future work
1 Summary
2 Future work
Appendices
1 Grammars of modeling languages
1.1 SVL grammar
1.2 Customized SAL grammar for building automation domain
1.3 Customized SDL grammar for building automation domain
2 Application domain: building automation
2.1 Building automation: vocabulary specication
2.2 Smart building application: architecture specication
2.3 Fire detection application: architecture specication
2.4 Building automation: deployment specication
3 Publications
References
