Application development for the Internet of Things: A context-aware mixed criticality systems development platform

ARTICLE IN PRESS

JID: COMCOM

[m5G;October 10, 2016;16:19]

Computer Communications 0 0 0 (2016) 1–16

Contents lists available at ScienceDirect

Computer Communications journal homepage: www.elsevier.com/locate/comcom

Application development for the Internet of Things: A context-aware mixed criticality systems development platform Carlos Kamienski a,∗, Marc Jentsch b, Markus Eisenhauer b, Jussi Kiljander c, Enrico Ferrera d, Peter Rosengren e, Jesper Thestrup f, Eduardo Souto g, Walter S. Andrade h, Djamel Sadok h a

Federal University of ABC, Av. dos Estados 5001, Santo André, Brazil Fraunhofer FIT, Konrad-Adenauer-Straße 53754, Sankt Augustin, Germany VTT Technical Research Centre, Kaitoväylä 1, Oulu, Finland d Istituto Superiore Mario Boella, Via Pier Carlo Boggio 61, Torino, Italy e CNet Svenska, Svärdvägen 3 B 4tr, Danderyd, Sweden f In-JeT ApS, Jeppe Aakjærs Vej 15, Birkerød, Denmark g Federal University of Amazonas, Av. General Rodrigo Octávio 6200, Manaus, Brazil h Federal University of Pernambuco, Av. Prof. Moraes Rêgo Av, Recife, Brazil b c

a r t i c l e

i n f o

Article history: Received 5 April 2016 Revised 15 July 2016 Accepted 29 September 2016 Available online xxx Keywords: Internet of Things System development platform Smart building Context-aware management Mixed–criticality systems Energy-efficiency management

a b s t r a c t The Internet of Things (IoT) is gaining momentum and may positively influence the automation of energyefficiency management of smart buildings. However, the development of IoT-enabled applications still takes tremendous efforts due to the lack of proper tools. Many software components have to be developed from scratch, thus requiring huge amounts of effort, as developers must have a deep understanding of the technologies, the new application domain, and the interplay with legacy systems. In this paper we introduce the IMPReSS Systems Development Platform (SDP) that aims at reducing the complexity of developing IoT-enabled applications for supporting sensor data collection in buildings, managing automated system changes according to the context, and real-time prioritization of devices for controlling energy usage. The effectiveness of the SDP for the development of IoT-based context-aware and mixedcriticality applications was assessed by using it in four scenarios involving energy efficiency management in public buildings. Qualitative studies were undertaken with application developers in order to evaluate their perception of five key components of the SDP with regard to usability. The study revealed significant and encouraging results. Further, a quantitative performance analysis explored the scalability limits of the IMPReSS communication components. © 2016 Elsevier B.V. All rights reserved.

1. Introduction Having been around for since the early 20 0 0 s, the Internet of Things (IoT) is rapidly gaining momentum as the availability of “things" significantly increases [1]. IoT has a major impact on smart Energy Efficiency solutions that can be used to analyse building performance data coming from distributed sensors and interact in an autonomous manner with higher-level services in order to build advanced building control applications. However, the development of IoT-enabled applications for the benefit of our society

∗

Corresponding author. E-mail addresses: [email protected] (C. Kamienski), marc.jentsch@fit. fraunhofer.de (M. Jentsch), markus.eisenhauer@fit.fraunhofer.de (M. Eisenhauer), jussi.kiljander@vtt.fi (J. Kiljander), [email protected] (E. Ferrera), [email protected] (P. Rosengren), [email protected] (J. Thestrup), [email protected] (E. Souto), [email protected] (W.S. Andrade), [email protected] (D. Sadok).

still depends on specific knowledge and tools that prevents it to be widespread. Many software components have to be engineered from scratch to address fragmentation issues, thus requiring huge amounts of effort, as developers must have a deep understanding of the technologies, the new application domain, and the interplay with legacy systems. Also, such systems face many challenges, such as dealing with a huge numbers of sensors and actuators, with mixed-critical applications that require real-time actions and with the need of automated systems based on context-aware management for adapting their behavior to current environment conditions. There is an evident need for new systems to be developed as IoT–enabled solutions become increasingly more common and Energy Efficiency being imperative in the world agenda today. Energy Efficiency is one of the main targets of the Europe 2020 Strategy for smart, sustainable and inclusive growth adopted by the European Commission [17] and of the National Energy Efficiency Plan of

http://dx.doi.org/10.1016/j.comcom.2016.09.014 0140-3664/© 2016 Elsevier B.V. All rights reserved.

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM 2

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

the Brazilian Electricity Regulatory Agency [24]. Buildings account for 40% of final energy consumption in the EU [16], so that investing in Energy Efficiency measures in buildings can yield substantial savings. Greater use of Energy Efficiency technologies, combined with renewable energy, offers significant potential energy savings and CO2 emission reductions in both new and existing buildings. However, a key challenge for the development of Energy Efficiency approaches for public buildings is that management systems must be easy to develop, deploy and use [14]. In the US, the lack of data on the actual energy performance, combined with the physical and operational characteristics of buildings is one of the primary challenges to expanding the building Energy Efficiency refurbishment market [13]. In order to deal with this challenge, we developed an IoT Systems Development Platform (SDP) within the IMPReSS project1 , which enables rapid development of context-aware mixed-criticality IoT–enabled applications. IMPReSS SDP focuses on Energy Efficiency management in public buildings as its first target, but it is also usable for any system intended to embrace a smarter society. The platform comprises a variety of components for making the task of developing IoT–enabled applications easier. These include tools for rapid development of user interface, pre-prepared software and middleware components, mixed-criticality resource management [8], context-aware data storage, analysis, and management [23], and IoT wireless communication management. Additionally, typical middleware components for dealing with energy efficiency management in public buildings are provided that hide the implementation complexity from the application’s developers. In this paper we introduce the IMPReSS approach and discuss the lessons learned from developing and testing IoT–enabled Energy Efficiency applications. An IMPReSS prototype system was developed, deployed and used in different application scenarios for different purposes, such as assessment, demonstrations, troubleshooting, and performance analysis. The main achievement demonstrated with the IMPReSS SDP is a portfolio of applications for decreasing the complexity and cost of collecting massive amount of energy related data in buildings as well as raising user awareness about energy consumption and efficiency. The IMPReSS SDP allows developers to create and experiment with new smart energy management services and use IoT enablers to fuse physical data to appropriate data analysis and control systems. The key functionalities provided by the IMPReSS Middleware are implemented by four main components, dealing with data, context, resource, and communication management. The effectiveness of the IMPReSS SDP for the development of IoT–based context-aware and mixed–criticality applications was assessed through four scenarios involving energy efficiency management in public buildings. The first scenario is a university classroom with energy efficiency context-aware automated lighting and temperature control. The second scenario is an alarm system, where the application–level mixed-criticality system orchestrates and prioritizes the components that can access resources. The third scenario is the monitoring of energy consumption in a historic public theatre building that uses legacy data storage and analysis features to highlight the energy savings obtained. The fourth scenario shows how a power outage in a university campus is managed using device-level mixed-criticality resource management. For the evaluation of the platform, a user-perception study was undertaken and five key components of the IMPReSS SDP were evaluated with regard to usability. A group of developers used the SDP to complete programming tasks involving the five features and gave their feedback about their experiences using a standard User Experience Questionnaire (UEQ) [22], which captures the usabil-

1

http://impressproject.eu

ity and perceived user experience of a product. The IMPReSS SPD received a very positive usability evaluation, which confirms that the IMPReSS SDP offers application developers easy-to-use tools for developing smart city applications. The key contributions of this paper are threefold. The first contribution is the IMPReSS architecture and implementation, which facilitates the development process of IoT–enabled applications, especially for energy efficiency management in public buildings. When compared to other approaches, the IMPReSS Architecture provides general-purpose built-in features that streamline the work of application developers. The second contribution is a set of four applications developed using the IMPReSS approach for evaluation and demonstration purposes, giving us confidence in the effectiveness of the platform. The third contribution is the positive results obtained from a qualitative analysis of the SDP undertaken by system developers and a quantitative analysis of scalability limits of the communication manager. In the remainder of the paper, Section 2 presents background and literature review, Section 3 presents the IMPReSS SDP architecture and Section 4 presents its key middleware components. Further, Section 5 shows four applications developed with the IMPReSS SDP and Section 6 presents the results of the evaluation with developers. Section 7 shows results of a performance analysis study that highlights the scalability of the Communication Manager. Finally, Section 8 draws some conclusions and paths for future work. 2. Background and literature review This section covers key aspects related to the design and implementation of a context-aware mixed-criticality development platform for IoT–enabled applications. 2.1. Software architectures for IoT Software architecture can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations [4]. They also play a key role as a bridge between requirements and implementation and therefore it was very relevant to the IMPReSS project. The process of building software architectures for IoT involves the interaction of a variety of components with different roles. The IoT–A project proposed an architectural reference model and a preliminary set of buildings blocks, in order to promote a fully interoperable and scalable vision of IoT [5]. The foundation of the IoT–A reference model is the IoT domain model, which introduces the main concepts of the Internet of Things like devices, IoT services and Virtual Entities (VE), as well the relations between these concepts. The abstraction level of the IoT domain model also has been adopted in this work due to its concepts are independent of specific technologies and usecases. Particularly, the IoT–A functional model played an important role in the specification of the IMPReSS software architecture, comprised of Functionality Groups (FG) and their interaction. 2.2. Design issues of middleware for IoT Building interoperable IoT services and applications requires a set of middleware components and system development and deployment tools for rapid software development. In order to avoid developing extremely focused and vertical IoT applications not able to interact with other applications, common and generic middleware services used by different application domains become necessary. Razzaque et al. [26] identified a variety of requirements in different categories for an IoT Middleware, which are also aligned with the functionality groups identified by IoT–A. IMPReSS

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

meets some of these requirements, such as resource discovery, resource management, data management, code management (allocation and migration), timeliness (real-time features provided by mixed-criticality mechanism), service-based programming abstractions (REST APIs), interoperability through different networks and technologies for providing autonomous adaptiveness. One of these IoT requirements is offer means for enabling the cooperation between objects and humans and creating awareness about the surrounding (context awareness) in a fully connected environment. Context-aware systems can be defined as systems that are able to adapt their behavior to the current context conditions without explicit user intervention [3]. In the IMPReSS SDP, context awareness is an important component of a middleware aimed at enabling rapid development of IoT–enabled applications, mainly for controlling energy efficiency systems [21]. Unlike most of the previous literature, context-awareness in IMPReSS is mostly focused on the needs and requirements of IoT–enabled future systems following the trend documented by Perera et al. [23]. In addition to the ability to adapt to current context conditions, different IoT– enabled applications are expected the share and perform real-time control of infrastructures composed of a huge number of sensors and actuators. Therefore, in many applications the integration of components with different levels of criticality is not only necessary but essential. Mixed Criticality Systems (MCS) are able to manage and execute applications with different criticality levels sharing common resources, while at the same time enforcing their requirements [29]. Applications with different criticality requirements that must be safely isolated from each other at the same time they share resources are likely to co-exist in an IoT–based world. LinkSmart (formerly known as Hydra [12]) is a middleware for facilitating the development of ambient intelligence applications that use device and sensor networks. LinkSmart is composed of a large number of components, or managers, that handle a variety of tasks needed to support cost-effective development of intelligent applications for networked embedded systems. Examples of managers are the service manager, event manager, device manager, network manager, storage manager, context manager and security manager, which are grouped into application and device elements. LinkSmart may be considered a predecessor of IMPReSS, since the latter uses and extends some components of the former, particularly the network manager. IMPReSS focuses on true IoT–enabled applications, whereas LinkSmart is contextualized in a pre–IoT era. For example, IMPReSS provides data management services for handling a huge amount of data generated by sensors, which is missing in LinkSmart. Also, LinkSmart does not provide mixed criticality features, which are a key feature of IMPReSS. 2.3. Development tools for IoT IMPReSS also provides tools for making it easier for developers to create IoT applications, specifically for energy efficiency management. It represents a step towards a fully integrated tool that will free IoT application developers from dealing with specific technological challenges, such as network protocols, data formats and data management. However, while the number of connected things increases rapidly and the volume of data is getting overwhelming, the process of developing IoT applications is still a complex task, so that there is a long avenue to be travelled. In order to create IoT systems, developers usually have to combine a diversity of non-integrated tools and programming platforms. Aiming at providing developers with a more appropriate integrated tool for IoT applications, IoTLink [25] has been introduced as a development toolkit called IoTLink, based on a modeldriven development (MDD) approach [20]. IoTLink offers an easyto-use graphical interface where inexperienced developers are able to create IoT applications using a mashup-like style by configur-

3

ing and wiring components together. Through visual components, IoTLink encapsulates the complexity of communicating with devices and services on the Internet and abstracts them as virtual objects that are accessible through different communication technologies. The model generated by the MDD-based GUI can further be transformed into a Java code, which can be extended by more experienced developers in a further phase of the development. IMPReSS goes beyond IoTLink in the sense that the latter works as a standalone tool whereas the former follows a client/server architecture where some of the components can be placed anywhere, as well as in the cloud. IMPReSS is divided into loosely coupled GUI components that may run in different classes of machines or devices and middleware components that run independently in the background. IoTLink integrates tightly coupled components into a logically single application. Also, IoTLink does not provide all features offered by IMPReSS, where its most noticeable missing feature is mixed-criticality. The long-term vision of IoT application development is a single horizontal ecosystem of interoperable objects and services that can seamlessly cooperate to make things useful for users. Song et al. [28] proposed a reference workflow for IoT system design and development that requires tight collaboration and integrated tools working together. While they deem the existence of support tools as a key feature of IoT system development, authors consider that specific IoT fields should use their specific tools. IMPReSS advocates that the set of tools should be seamlessly integrated into a unified System Development Platform (SDP), while allowing external tools to be integrated through open interfaces. 2.4. IoT-based energy management in public buildings Recent research on buildings focuses on improving occupant comfort at the same time that energy usage is reduced [9], which is a challenging problem since buildings and particularly HVAC account for 40% and 32% of energy consumption in industrialized countries, respectively [27]. Building Energy Management Systems (BEMS) are computer-based systems that monitor a building’s energy and comfort status and controls building subsystems such as ventilation, lighting, and energy distribution and storage systems. The BEMS market enjoys high growth rates as a result of increasing cost of energy and the continued focus on low-carbon operations. However, the efficiency of the BEMS tools is highly dependent on measurement and control aspects of energy consumption. The US Department of Energy highlighted the lack of data on the actual energy performance, combined with the physical and operational characteristics of commercial and residential buildings as a key challenge to expanding the building energy efficiency refurbishment market [13]. Also, the lack of standardized metadata for identifying sensors requires labelling to be done manually, which is time consuming and error prone. BEMS may suffer from lower efficiency in energy usage due to such constraints. Currently, there are different proposals for dealing with (semi-) automated labelling (or naming) schemes for sensors, such as active learning [2], expert-based mapping techniques [7] and similarity finding based on linguistic and semantic techniques [27]. IMPReSS SDP is a platform for application development in IoT–enabled buildings. Even though it operates on a higher level than sensor-specific naming issues, it is influenced by and may be benefited from new contributions regarding the collection of data from a massive number of sensors in buildings. The IMPReSS SDP aims at reducing the complexity and cost of developing intelligent systems for supporting massive collection of energy related data in buildings and building complexes. It allows developers to create and experiment with new smart energy management services and use IoT enablers to fuse physical data

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

ARTICLE IN PRESS

JID: COMCOM 4

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

• Integrator: The solution integrator installs, configures and deploys applications, and connects them to other external services and hardware components. • Recipient: The final recipient is directly affected by the solution, such as employees of an organization, audience of a theatre and university staff. The IMPReSS software architecture adopts four views, one for each stakeholder. Fig. 2 presents the interaction of the four views, the external components (hardware and software) and the dataflow between stakeholders, starting with the Creator’s view and following a right-to-left direction. IMPReSS creators have the responsibility to perform and fulfil the tasks related to the project. In the end, the System Development Platform (SDP) will be developed and used by Application Developers, showed in the Developer’s view. Developers also must interact with physical and digital resources when developing their applications, which in turn are used by the Solution Integrator. Integrators also configure physical resources and connect external services (digital resources) to deploy ready-to-use solutions to the final recipient. Fig. 1. IMPReSS domain model.

3.3. IMPReSS architecture to allow appropriate data analysis and control systems. Moreover, long-term working data models and interfaces can be provided by the IMPReSS platform which may further enhance energy management decision support systems to achieve a better understanding of building energy performance. 3. IMPReSS SDP architecture The IMPReSS SDP is defined by its domain model, stakeholders and views and its architecture made of software components divided up into user interface and middleware layers. 3.1. IMPReSS domain model To both facilitate interoperability and make the IMPReSS architecture easier to understand by external developers, the IMPReSS domain model closely follows the models and terminology proposed by the IoT–A Architectural Reference Model (ARM) [5]. In the IMPReSS domain model, the physical world objects that are relevant for the given IoT system are referred to as IoT Entities, as shown in Fig. 1. IoT entities can be human beings (e.g., eHealth related IoT system), inanimate non-digital objects (e.g. food products), places (rooms, buildings, etc.) or devices (home appliances, servers, etc.). The domain specific business logic, which specifies how users interact with IoT entities is realized by applications developed with the IMPReSS SDP. The interaction between the application and IoT entities is via IoT resources (i.e., sensors and actuators), which provide applications with means to monitor and manipulate the physical world. In other words, IoT resources expose the actuating and sensing capabilities of devices distributed into the IoT environment. 3.2. IMPReSS stakeholders and views Four types of stakeholders have been identified for IMPReSS, each one with particular interests and concerns, which influence the architecture design. The terms “user" or “end-user" were intentionally avoided because they can assume meanings that vary according to different contexts. • Creator: The IMPReSS creator actively contributes to the development of the IMPReSS SDP. • Developer: The application developer uses the IMPReSS SDP to develop IoT-enabled Applications.

The creator’s view of the IMPReSS Architecture (or simply IMPReSS Architecture) shows that the SDP is composed by two broad categories of software components, namely the IMPReSS User Interface (UI) and the IMPReSS Middleware, as shown in Fig. 3. The UI contains a series of components for allowing users to interact with the platform and the middleware contains components with background management responsibilities. IMPReSS assumes that data is stored somewhere in the cloud, using conventional databases or novel ones (such as NoSQL). Also, IMPReSS does not adopt a one size fits all approach for data storage, making it possible for different database models to be used for different middleware modules. Components of the UI have counterparts as middleware components connected through the IMPReSS API. • Data UI: aims at allowing developers to configure the data analysis and support module that uses supervised and unsupervised learning for helping IMPReSS applications to make more informed decisions, based not only on real time but also historic data. • Context UI: aims at managing context information, for allowing developers to specify which features they need in their applications, ranging from context entities such as fusion criteria and rules. • Resource UI: aims at allowing developers to specify all particular information needed for the mixed criticality resource management, which may be performed through parameterization or through a specially designed applications classification language. • Communication UI: aims at allowing developers to specify all information needed for dealing with communication with resources in the IMPReSS Middleware. The IMPReSS middleware components offer background services for their UI counterparts: • Data manager: provides data storage and retrieval features, such as historic context information, as well as implements data analysis and machine learning algorithms. • Context manager: simplifies context recognitions and management for context-aware applications, such as data fusion and reasoning. • Resource manager: manages the mixed-criticality system, schedules, and prioritizes access to resource constrained devices, and subsystems.

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

5

Fig. 2. IMPReSS architecture views.

Fig. 3. IMPReSS architecture (creator’s view).

• Communication manager: provides and abstraction layer for allowing the communication among different devices via the Resource Adaptation Interface (RAI). 4. IMPReSS middleware components The key functionalities provided by IMPReSS Middleware are implemented by four main components: data manager, context manager, resource manager and communication manager. 4.1. Data manager The data manager provides data and knowledge storage and features retrieval, as well as implements data analysis, stream management and data mining. The data and knowledge storage maintains information such as historical sensor data and inferred knowledge, enabling the storage and retrieval of both raw data and enhanced information for other components. The recognition of the modelled situations requires understanding the technicalities of each sensor and using fusion techniques to combine readings from different sensors.

The IMPReSS platform is based on a property graph model as the paradigm for modelling an IoT–enabled environment and a NoSQL database that overcomes the well-known limitations of the relational model to deal with non-structured information. Graph databases provide a natural and flexible way to represent information about real world as well as built-in structures for the data. The data modelling is based on sensor readings arranged in a certain physical environment. The setting may have an infinite number of areas, which in turn may or may not embody other areas within it. Each area may contain an indefinite number of devices that perform several measurements of the various parameters throughout the day, while it is necessary to store a history of such readings possibly for an indefinite time, depending on application requirements. At a measurement per second rate, a single device may produce more than 31 million measurements in a year. Querying over this data requires strategies on many levels, as quality of searching algorithms and schema efficiency. The storage module uses a hierarchical tree as a time series organization structure. Each measurement is posted with a timestamp and an address of its source

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

ARTICLE IN PRESS

JID: COMCOM 6

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

Fig. 4. IMPReSS storage architecture.

device. This way the storage can create intermediary nodes with aggregated data. The data and knowledge storage uses OrientDB2 , which allows IMPReSS data model to be represented without any modifications. As a query language, OrientDB has a Java API based on Gremlin traversal language, a functional graph query, analysis, and manipulation language. The Java API allows providing resources of the IMPReSS IoT domain expressively via RESTful API, hiding the complex business logic of graph algorithms and enabling rich query parameters, such as ranges of dates for querying a device or group of devices. Fig. 4 shows the storage architecture. The measurement hooks component contains triggers for OrientDB that work as organizers for measurements (removing and aggregating, when necessary). In IoT, data are generated everywhere at anytime. Therefore, the continuous data processing, also referred to as streams, must reflect the ubiquitous nature of the data generation. In IMPReSS, the ubiquitous or distributed data mining is performed by the IoT learning agent, which works in five phases. In the first phase, data transmission and collection, data is transferred from the sources to the processing software, via the communication manager (Section 4.4). In the second phase, data pre-processing phase done in (near)real-time, using stream processing techniques such as Complex– Event Processing [11] engines. The third phase is about learning, based on increasing and interactive phase. Validation is the fourth phase, in which the learning process is assessed using continuous evaluations through accumulated evaluation metrics (e.g. accuracy for classification or root mean squared error for regression) of each data point and prediction made by the model. The last phase is deployment. If the validation metrics reach the thresholds, the model is deployed in the system. 4.2. Context manager The IMPReSS context manager provides context templates, modelling, reasoning and tracking, as well as algorithms for sensor data fusion [21]. Two main design choices guided the techno2

http://orientdb.com

Fig. 5. IMPReSS context manager.

logical choices: object-oriented context modelling and rule-based context reasoning. There already exist some very mature underlying technologies such as persistence storage and rule engines that are based on the object-oriented approach. In addition, rule-based reasoning is commonly used and offers different existing tools that integrate with object-oriented programming languages. IMPReSS aims at providing reusable templates for energy efficiency context management, making it easier and faster to add context-awareness features in building automation applications. The design of context templates is characterized by context entities, their relationships, and their attributes. We identified seven entities that commonly exist in typical context-aware building automation applications: Subject (people), Resource (sensors/actuators), Place (rooms, floors), Fusion (data aggregation), Rule (decisions), Action (commands to actuators), Activity (schedule) and Context (set of other entities working together). IMPReSS allows context entities to be modelled as a Context Graph, where vertices represent entities (sensor, fusion, rule, actuator) and edges represent data and control flow between vertices. Fig. 5 depicts a simplified view of the context manager architecture. The context API exposes a REST interface, allowing other components to interact with the context manager. The context storage deals with context entity templates, using EclipseLink as object–relational mapping together with PostgreSQL. The data fuser uses a set of techniques for combining data from multiple sources or computing statistics. The fuser receives sensor data from the Communicator and when fusion criteria are met it activates the Reasoner or alternatively fused data may become a virtual sensor and be redirected back to the Fuser. We use Esper [15], a complex event processing engine, for filtering, analyzing, and fusing events in various ways, configurable through an SQL-like language. The context reasoner infers logical consequences from a set of facts. It searches the entire set of rules for a match, i.e., a rule that matches the parameters. As a result of firing a rule, one or more actions are performed and they usually refer to sending commands to actuators for changing the configuration of devices or equipments for dynamically adapting behavior, e.g. turning off an elevator or lowering the temperature of an air conditioner. Our implementation

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

7

Fig. 6. IMPReSS resource manager.

is based on Drools3 (Expert and Workbench). The context tracker provides an implicit way for identifying contexts that effectively were executed, by tracking back actions executed by actuators up to the sensor data that caused them and finally creating the context graph. Finally, the communicator encapsulates communication with resources via the communication manager. 4.3. Resource manager The resource manager provides mixed criticality resource management at device and application levels [29]. At device level its role is to control the power feed to IoT devices so that more critical devices are provided with power in case there is limited amount of energy available in the system (e.g. in the case of a power outage). At the application-level the resource manager controls how IoT applications access distributed IoT resources (i.e., sensors and actuators) provided by the IoT system. The conceptual mixed criticality resource management architecture is depicted in Fig. 6. It consists of application & resource descriptions, resource management middleware and tools to support development, monitoring and maintenance of mixed criticality in IoT domain. The resource management middleware can be further divided into two levels, system and resource, which are implemented by the Global Resource Manager (GRM) and Local Resource Manager (LRM) respectively. The GRM consists of following modules that communicate with each other and the rest of the IMPReSS platform with Websockets [19]: System Knowledge Base (SKB), Application–level Resource Manager and Device–level Resource Manager. The SKB in an internal database of the GRM, storing information about applications, IoT resources, IoT entities and associations.

3

http://www.drools.org

The fundamental idea behind the application-level resource management is to make it possible to deploy and execute multiple independent IoT applications on the same IoT platform without compromising the behaviour of critical applications. A key design choice in the mixed criticality resource management approach is to represent IoT resource specifications (and descriptions) with Semantic Web knowledge representation [6], so that we can better address the challenge of dealing with resource heterogeneity and the need for future extendibility. The Application–level Resource Manager (ARM) is responsible for managing how applications developed with the IMPReSS platform access IoT resources. Whenever new applications are deployed into the system the ARM first authenticates the applications using a customized OAuth2.0– based process. If it succeeds, the Application–level Resource Manager subscribes to all IoT resources that match the specifications represented in the application description. If multiple applications try to reserve the same resource with exclusive access scheme the most critical application is authorized. The Device–level Resource Manager controls the power feed to devices based on device criticality so that enough energy is available for the most critical devices. The approach is based on the assumption that in the case of a power outage all the devices are powered by the same emergency supply (e.g. generator or battery). The Device–level Resource Manager needs to be configured for each individual IoT system so that it meets the requirements of the given environment. At the application level, the role of the Local Resource Manager (LRM) is twofold. First, it controls that only the applications authorized by the GRM access the resources. Second, it schedules requests made by applications so that operations made by applications with higher criticality levels are prioritized over operations requested by less critical applications. At the device level, in turn, the role of the LRM is to control the power feed to the physical devices according to commands send by the GRM.

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

ARTICLE IN PRESS

JID: COMCOM

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

MQTT

XMPP

Resources monitoring and control

HTTP REST

XMPP

MQTT

UPnP

Discovery and Configuraon management RAI Config

RAI Config!

RAI Commands

RAI Discovery

HTTP REST

RAI Events

RAI CONNECTORS

8

[m5G;October 10, 2016;16:19]

RAI API

Discovery

Events

Config!

Commands

RAI

RAI Core

Device Templates

RAI Device Managers Kinect Manager

Plugwise Manager

Kinect Kinect Discovery \ Virtual Manager Resource

Plugwise Plugwise Discovery Virtual Manager Resource

Philips Hue Manager P. Hue Discovery Manager

P. Hue Virtual Resource

Xively Manager Xively Discovery Manager

Xively Virtual Resource

Enocean Manager Enocean Enocean Discovery Virtual Manager Resource

...

Fig. 7. IMPReSS resource adaptation interface architecture.

4.4. Communication manager The XMPP-based communication manager [18] provides means for abstraction, discovery and seamlessly interconnection of the physical world, i.e. sensors and actuators, with logical entities in order to allow the development and deployment of IoT applications even to non-technical users. The communication manager utilizes the core security features of the XMPP protocol to ensure security. This includes tunnelling communications over TLS, authentication via SASL, and access control via XMPP built-in mechanisms. SASL is a flexible mechanism for authentication that supports a number of different systems including token-based approaches such as OAuth2 or Kerberos, username/password, or X.509 certificates [10]. The IoT communication infrastructure consists of four components: a) The Resource Adaptation Interface (RAI) enables seamless and automatic virtualization of heterogeneous physical IoT resources; b) The IoT Resource Catalogue discovers and keeps track of available IoT resources in the network; c) The Lightweight Middleware Infrastructure allows the system to scale down or up easily for different types of physical communication gateways; d) The Network Management Infrastructure reduces network management effort by automating the association between the physical deployment of IoT gateways and services that access them. RAI is a lightweight abstraction layer able to run on low-power resource constrained gateways, composed of a set of interfaces that can be used to monitor and control application-level resources. Its modular architecture allows dynamically plugging and unplugging relevant drivers for managing different IoT resources. RAI is located on the extreme edge of the IMPReSS platform, just above the hardware and software resources and its architecture has been designed to be modular and extensible through the addition of new resource drivers abstracting new, previously unhandled, entities. RAI can abstract both physical resources (e.g. sensors, actuators) and third-party services (e.g. weather forecast services). The RAI virtualizes each resource as a virtual device that exposes functionalities, provided by physical devices or third-party services. These interfaces are derived from a set of resource models that describe minimal methods/services of a basic set of resource types

(e.g. temperature sensor and humidity sensor). The interfaces provided by RAI are used by the Local Resource Manager (LRM) to interact with the available resources. Fig. 7 depicts the RAI architecture, composed of three layers. The lower layer of the architecture consists of a set of technologyspecific device manager classes responsible for the actual integration of different resources. These components are able to handle specific types of networks and they contain the implementation of specific device discovery features. A set of application-level resource models, stored in a dedicated repository, is used for the virtual device interface definition. For the current implementation of the RAI, these models consist of a set of Java interfaces that define a basic number of methods/services provided by the most common device types. The middle layer is the RAI core, which is in charge of mapping the southbound devices and to notify upper layers about network changes. The upper layer is responsible for exposing methods/services provided by the resources. This layer is composed of the APIs offered, in order to retrieve and manage virtual devices and call their resource-specific methods. The adaptive security manager (ASM) is responsible for securing the communication between wireless sensors and the RAI. It can select the required level of security according to inputs from a state-of-the-art Intrusion Detection System (IDS) and inform the particular resource about it. This makes it possible to support both suitable security according to the actual criticality level and also increase the lifetime of battery powered wireless devices, which do not need to use long and energy consuming encryption keys all the time. Based on commands from the ASM, wireless sensors can select a suitable key from pre-shared keys. The IoT resource catalogue provides mechanisms for routing requests regarding the physical world to the appropriate software resource that is able to fulfil the request, such as reporting the temperature in a particular office space or the current electricity consumption of a household appliance. It provides a REST-based interface to select and retrieve data about IoT resources and their services. The Lightweight Middleware Infrastructure allows the system to easily scale down or up for different types of physical communica-

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

Fig. 8. Context-aware energy saving scenario -– classroom.

tion gateway. The communication manager has been designed with exchangeable backbone network as plugins. The backbone network has been leveraged on lightweight communication protocols that have gained a lot of support from IoT community and would work for both ARM and ×86 architecture. The Network Management Infrastructure consists of two independent solutions: Remote IoT gateway software-management framework, which provides means for simple packaging and remote management of IoT gateway software, and zero-effort IoT network context management, which provides means to create and manage the context (i.e., IoT resources, IoT entities and associations between them) of an IoT system. 5. Proof-of-concept applications The effectiveness of the IMPReSS SDP for the development of IoT-based context-aware and mixed-criticality applications was assessed by using it in four scenarios (use cases) involving energy efficiency management. 5.1. Scenario 1: context–aware energy saving This scenario aims at showing how the IMPReSS platform may be used for context-aware energy-efficiency management, where the system automatically adapts according to current environmental conditions. A case study was developed to represent a scenario of a university classroom, where the context manager automatically controls lighting and temperature. A set of rules is used to adapt the behaviour and fusion criteria of pre-processed data from sensors. Initially there are two applications (energy saver and alarm system) and three types of IoT resources (ultrasonic presence sensor, lights, smart plugs) deployed into the system. The light control is guided by the context entity “row occupied” that determines presence in particular rows of the classroom, so that rules decide whether to turn lights on or off. Fig. 8 represents a simplified classroom with four rows and four individual lights (L1, L2, L3, L4), four ultrasonic presence sensors (U1, U2, U3, U4) and two Kinect sensors (K1, K2). Ultrasonic sensors are installed one per row and Kinect sensors one each two rows since they have a wider angle. Table 2 shows an example of five rules used in this scenario to turn lights ON and OFF according to the presence of students in specific rows of the classroom. The rationale for this example is that if back rows are empty, lights can be automatically turned OFF but whenever there is at least one student in a certain row, all lights from that row frontwards are turned ON. For example, R1 says that when there is a student in row 4, ultrasonic sensor U4 detects it and therefore the lights of all rows will be turned ON. On the other hand, rule R4 says that when there are students in row 1 and the other rows are empty, lights from rows 2, 3 and

9

4 can be turned OFF but lights from row 1 must be turned ON (Table 1). An important limitation from this phase of the scenario is that the presence of detection sensors often report false positives, so the second phase shows how new IoT Resources can be easily deployed to enhance existing systems. Since no modifications are required in the existing applications because of the IMPReSS platform, Kinect sensors were added to the system to improve presence detection. The Integrator searches for a driver that is available for Kinects (already added to the platform by the Developer) and the driver is installed at runtime in its RAI instance, using the Communication UI. Finally, the IoT Resource Catalogue, interacting with the Local Resource Manager, discovers the IoT Resource, abstracted by the RAI. The Integrator accesses the Context Manager, through the Context UI, and notices that a context called Row Occupied is defined through interpretation of the ultrasonic presence sensors. In turn, the Integrator extends this context for considering a fusion of values from the existing presence sensors and the Kinects. Since Kinect sensors detect presence in two rows at once, data coming to the Reasoner are represented by two bits, after passing by the Fuser: 00, 01, 10 and 11. For example, 01 means that at least one person was detected in the right row but no one was detected in the left row. Table 2 shows the new rules needed by the scenario. The presence in a row must be detected by both ultrasonic and Kinect sensors for lights to be turned ON from that row frontwards. Please notice that these rules are only examples that can be adapted for any particular application as developers or integrators see fit. In our example, conditions can become complex as in R8, where the systems has to guarantee that there is no presence in rows 4 and 3 but there is presence in row 2. Information coming from Kinect sensors is represented by K2 == 00 and the left row sensed by K1 (row 2) being 1 (i.e. K1 == 11 or K1 == 10). Now, in order to turn on lights, two types of sensors must confirm presence information. As part of the configuration phase the Kinects must be added to the mixed criticality management, which determines which power consumers shall be switched off in case of a power outage. For this, all managed devices are connected to switchable smart plugs. The Integrator accesses the resource manager and detects that so far only an emergency light and two servers have high priority assigned and the remaining power consumers in the classroom have low priority. Consequently, the developer can also assign low priority to the Kinects. Afterwards, the Integrator performs a few tests again and empirically finds out that there are less false positives. In the third phase of the scenario, application level mixed criticality features are evaluated by making the Alarm System to take over the lights whenever an alarm signal is received from sensors (or simulated with an alarm button). When the alarm signal ends the Alarm System releases the lights and the control is granted back to the energy saver application. Device level mixed criticality is illustrated by a power outage, where the resource manager switches off the low priority devices in a timely manner. After some time when the fuel of power generators decreased to a certain level, the Resource Manager checks again if the power outage still occurs. If yes, it switches off the next class of devices. After the power outage ends, the Resource Manager makes sure to switch on all devices after the grid is stabilized. Higher priority devices are switched on before lower priority ones, which can be configured in the resource UI. Fig. 9 depicts the interactions among components of the IMPReSS platform for this scenario, where IMPReSS components are represented in white and applications in grey. The energy saver application interacts with the Context Manager only, whereas the alarm system application interacts with the Global Resource Manager (GRM) and the IoT Resource, which is a wrapper component,

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

ARTICLE IN PRESS

JID: COMCOM 10

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16 Table 1 Context–aware energy saving scenario – initial rules. Rule

Condition

R1 R2 R3 R4 R5

U4 == 1 U4 == 0 AND U4 == 0AND U4 == 0 AND U4 == 0 AND

Actions U3 == 1 U3 == 0 AND U2 == 1 U3 == 0 AND U2 == 0 AND U1 == 1 U3 == 0 AND U2 == 0 AND U1 == 1

L1, L2, L3, L4 ⇐ ON L1, L2, L3 ⇐ ON L4 ⇐ OFF L1, L2 ⇐ ON L3, L4 ⇐ OFF LA1⇐ ON LA2, LA3, LA4 ⇐ OFF LA1, LA2, LA3, LA4 ⇐ OFF

Table 2 Context–aware energy saving scenario – new rules. Rule

Condition

Actions

R6 R7 R8 R9 R10

U4 == 1 AND (K2 == 10 OR K2 == 11) (U4 == 0 AND U3 == 1) AND K2 == 01 (U4 == 0 AND U3 == 0 AND U2 == 1) AND (K2 == 00 AND (K1 == 11 OR K1 == 0)) (U4 == 0 AND U3 == 0 AND U2 == 0 AND U1 == 1) AND (K2 == 00 AND K1 == 01) (U4 == 0 AND U3 == 0 AND U2 == 0 AND U1 == 1) AND (K2 == 00 AND K1 == 00)

L1, L2, L3, L4 ⇐ ON L1, L2, L3 ⇐ ON L4 ⇐ OFF L1, L2 ⇐ ON L3, L4 ⇐ OFF LA1⇐ ON LA2, LA3, LA4 ⇐ OFF LA1, LA2, LA3, LA4 ⇐ OFF

Fig. 9. Context-aware energy saving scenario.

composed of instances of the Local Resource Manager (LRM) and the RAI. The Context Manager must interact with the GRM to obtain authorization to use actuators and also to the IoT Resource to receive data from sensors and send data to actuators. The IoT resource is controlled by the GRM and identifies new resources and registers them into the GRM and the RAI.

5.2. Scenario 2: application level mixed–criticality resource management This scenario extends Scenario 1 focusing on application-level mixed-criticality resource management aspects, thus emphasizing the role of the Application–level Resource Manager in Fig. 9. The application-level mixed-criticality resource management can be divided into two phases: deployment & discovery and resource access. At the beginning of the scenario the system setup is the following: there is an occupancy sensor and a smart light IoT Resource associated with each row in the classroom. For the sake of clarity only four rows are illustrated in this example. Two IoT applications (i.e., Energy saver and alarm system) are then deployed into the system and registered to the Application–level Resource Manager, which subscribes to the resource specification represented in the application description. There is a single suitable IoT Resource for each resource specification and the system knowledge base informs Application–level Resource Manager about these resources.

As the scenario unfolds, a Kinect sensor is deployed into the classroom and associated with the room and all its rows. This device is classified as an occupancy sensor and therefore it matches the occupancy sensor specifications of the Energy saver application. Similarly, the Application–level Resource Manager must be informed whenever a resource matching a resource specification is removed from the system. Thus, the Application–level Resource Manager has a real-time view about the most suitable resources for each specification and it is able to allocate them to the applications whenever necessary. Because of this design choice, no queries or semantic matchmaking need to be executed when the applications actually make a reservation to a resource specification and therefore its performance is significantly increased. When this scenario starts all other sensors except the Kinect are already deployed into the system. Then the Energy saver makes reservations to two occupancy sensors in each of the four rows. Upon receiving the resource reservation message, the GRM searches for suitable resources from its pool of free resources. In this case, there is one resource (i.e., an occupancy sensor) for each resource specification available and these resources are allocated for the application. There is also no suitable resources used by less critical applications so the GRM notifies the Energy Saver application about these resources and informs the LRMs of the occupancy sensors about which applications were granted access to them. When the Kinect sensor is deployed into the system, the GRM automatically reserves the resource for the Energy Saver application, because the Energy Saver initially reserved two IoT Resources for the occupancy sensor specification, and notifies it and the LRM about this reservation. When the Energy saver application detects that certain row is occupied (i.e., row four in this example), it reserves the lights for that row from the GRM because the Energy saver is the only application that has made a reservation of this resource, the GRM authorizes it and informs the given LRM about the situation. Later in the scenario the alarm system application receives a notification from a smoke sensor and makes reservations to all the IoT resources in the classroom in order to notify people using exclusive access scheme. Since it is more critical than the Energy saver app the resources are assigned for it and the corresponding LRM is notified about the situation. In the end of the scenario the alarm ends and the Alarm system application releases the resources. 5.3. Scenario 3: energy consumption monitoring in the Amazonas theatre IMPReSS was used to deploy an application for monitoring energy consumption at the Amazonas Theatre, located in Manaus

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

11

Fig. 10. Energy consumption monitoring web application.

Fig. 11. Energy consumption forecast.

(Amazonas state, Brazil). The theatre was inaugurated at December 31, 1896, at the peak of the economic rubber cycle and it is the major architectural cultural heritage of Amazonas. Amazonas Theatre was chosen because it is an attractive building to demonstrate the potential of IMPReSS to reduce energy usage in an existing public building. The purpose was to show a successful integration of a national historic heritage and green awareness and ecological sustainability. This application is mainly supported by the Data Manager, but also uses other IMPReSS components to have access to sensor data. Energy consumption data was obtained from Amazonas theatre in two different ways. Sensors were installed in electric panels at dressing rooms (no authorization was granted to make changes at any other room), thus making it possible to obtain energy consumption data in real time. Also, a crafted dataset was generated through the analysis of previous scheduled events in the Theatre during the period between January and December 2015. For that, measurements were based on a manual process performed by an ammeter at the Theatre power substation at three different situations: 1) during a performance; 2) during the day when no performance was taking place; 3) during the night, with no performance. As energy consumption varies according to these situations, measured data was used to generate a generic dataset according to actions occurred during certain period of time.

The energy consumption data management is managed by an IMPReSS-enabled web application, which shows energy consumption of the whole theatre divided by area (Fig. 10). In addition, it is possible to create energy consumption forecasts using predictive models of the data manager, such as the one depicted by Fig. 11. This task can be accomplished by using different regression algorithms available in the data manager where the Recipient is required to provide a dataset and a time range in the future and the result is a chart with historic and future values of energy consumption. Another functionality supported by the data manager is the ability to make recommendations to the Recipient such as to turn on or off a heating, ventilating or air conditioning (HVAC) system. This can be performed by a classification algorithm using a dataset with some attributes, such as room, timestamp, occupation and events. The result will indicate whether to turn the HVAC system on or not. 5.4. Scenario 4: device–level mixed–criticality - power outage in a university campus This scenario illustrates how IMPReSS Device–level MixedCriticality Resource Management can be utilized to handle power outages in the Federal University of Pernambuco at Recife, Brazil. Whenever a new IoT system is deployed, an Integrator needs to

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM 12

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

Fig. 12. Device-level resource manager configuration for the power outage scenario.

configure its behavior during a power outage by defining when different parts of the system need to be shut down and powered again. In practise, this is done by assigning criticality values for different IoT Resources and configuring simple power outage and wakeup phase rules. For a power outage period a rule specifies a device criticality level and a backup power supply threshold. Whenever, the energy level of a backup power supply drops below a certain threshold all devices with criticality value below the criticality threshold specified for that energy level are turned off. In this case the Integrator, who is an electrical engineer responsible for maintaining the power grid of the University Campus, configures following three rules with the Resource UI. 1. When icality 2. When icality 3. When icality

70% of the energy is available all the devices below critvalue 100 will be turned off; 40% of the energy is available all the devices below critvalue 200 will be turned off; 10% of the energy is available all the devices below critvalue 300 will be turned off.

When the power outage ends it is important that all devices are not simultaneously turned on in order to maintain the stability of the power grid. To this end, the resource UI provides means to create rules that define certain delays for different criticality levels (i.e., how long is waited after a power outage before devices below a certain criticality level are turned back on). In this scenario, the Integrator specified two rules that are: 1) immediately after the power outage is over all devices above criticality value 200 will be turned on; 2) after 30 s all devices above critical value 0 (i.e., all the rest of the IoT Resources) will be turned on. Fig. 12 depicts the configuration process in the resource UI. The Device-level Resource Manager relies on three types of external IoT resources; two sensor type IoT resources monitoring power outages and the energy available in the backup supply, as well as, an actuator type IoT resources that controls the power feed to the appliances. The technical functionality of these devices depends heavily of the target system (i.e., type of power grid, backup energy supply and appliances) and is out of the scope of the IMPReSS SDP (i.e., the IMPReSS SDP is a software platform that does not natively include any specific sensor or actuator devices but provides drivers and tools that makes it easy to integrate different types of sensors and actuators to IMPReSS-powered applica-

tion). In this case, power outages are detected by a standard power sensor, which monitors part of the University Campus power grid. As a backup power supply the University uses a generator, whose fuel level can be monitored with a camera. Plugwise smart plugs in turn are used to control the power feed to the appliances consuming energy in the power grid. It is assumed that a trustworthy person (e.g., the Integrator) updates information about the associations between IoT entities and IoT resources (i.e., appliances and smart plugs) so that the Device-level Resource Manager can make the correct actions. When a power sensor detects a power outage in the grid it notifies the Device–level Resource Manager, which immediately subscribes to energy level data provided by the energy level sensor. Whenever a new energy level notification is received, the Device– level Resource Manager checks whether new devices need to be turned off. In this scenario, when the energy level drops below 70% all devices whose criticality value is 100 or below are turned off. A similar process is executed when the energy level drops below 40% and 10%, and the Philips Hue lights and the Biology server are examples of devices affected by these drops respectively. When the power outage is over the Power outage sensor again notifies the Device–level Resource Manager, which initiates a wakeup procedure configured by the Integrator. In this scenario, it means that all devices that have 200 or higher criticality are turned on immediately.

6. User evaluation In order to evaluate the IMPReSS SDP with respect to perceived ease of use, efficiency and applicability to real life development task, a usability study was conducted with external developers. The evaluation encompassed the use of the overall IMPReSS platform as well as specific evaluation of the five key components. The purpose of the evaluation was to obtain an understanding of how external developers perceive the IMPReSS platform as a whole. However, for practical reasons the participants evaluated the platform through the graphical development kit tools and not the middleware components directly. In other words, the participants’ perception may be somewhat biased by the user-friendliness of the graphical development kit, rather than evaluating the efficiency of the tools in the development of a full application.

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

6.1. Evaluation setup The user evaluation study was performed with ten participants in a two-hour workshop. The participants’ prior experience in IoT application development ranged from low to high in a well-balanced distribution. The participants were assigned in five groups of two. At the beginning of the workshop, the IMPReSS platform was introduced to the participants. Afterwards, each group tested and assessed each component only once using the following approach: a) each of the five components was made available at an individual station; b) each station contained a preconfigured machine with a running IMPReSS SDP and the stations were independent from each other; c) the 5 groups were distributed over the 5 stations and rotated after having finished one station, so that in the end, every group had visited each of the 5 stations. At each station, an IMPReSS member (Creator) gave an introduction to the respective component. Afterwards, the group could try out the component as long as desired. During that time, the IMPReSS member stayed around in order to answer questions. Then, the group was asked to conduct small programming tasks with the tool. In this way, the participants could get a feeling of using the IMPReSS SDP and how it could support application development in practice. The individual tested tools and the programming tasks are described in Section 6.2. After completing a task, participants were asked to fill out the User Experience Questionnaire (UEQ)4 [22], which captures the usability and user experience perception of a product. We used a slightly modified version of the standard UEQ scheme, as we added six additional items so that the scheme contained 32 different items describing various aspects of the perceived usability of the component. Each item has the form of a semantic differential, i.e. each item is represented by two terms with opposite meanings such as “easy to learn – difficult to learn”, “fast – slow”, “motivating – demotivating”. The user was asked to assess each item on a scale from 1 to 7 with 1 being the lefthand semantic attribute and 7 the right-hand semantic attribute. The UEQ applied in this evaluation, uses the seven-stage scale used to reduce the well-known central tendency bias for such types of items (if uncertain, respondent checks the central attribute). In the analysis, the items was categorised into six dimensions each containing 4–6 items on the UEQ. Each of the dimensions describes a distinct quality aspect of the component: Attractiveness, Efficiency, Perspicuity (fluency), Dependability, Stimulation and Novelty. 6.2. Evaluated components First, the users evaluated the five selected IMPReSS components individually and where then asked to evaluate the tools as part of a full Software Development Platform. • Application Description Generator: Being actually a part of the mixed criticality resource management, this task was a little smaller than others. However, we considered it big and separate enough to be used as own task. The idea of the application description generator is to use an intuitive graphical tool for generating a rather complicated JSON file including SPARQL queries, which need to be created for every new application that requests control over an IoT resource. As a task, participants were asked to create and finally download such a JSON file. The parameters to be entered were indicated. The application should be registered for two resources • Resource Adaptation Interface: The Resource Adaptation Interface (RAI) is used to see and manage all IoT devices, which are 4

http://www.ueq-online.org

13

currently managed by the IMPReSS instance. In that sense, participants were asked to find out information about the currently managed devices as well as also performing device management actions. In particular, participants had to find out what the currently connected networks are, how many devices are currently connected and how much power in Watt a particular smart plug currently measured. For device management, a new device driver needed to be installed into the RAI instance and one smart plug network needed to be stopped and started over. • IoT resource catalogue: The IoT resource catalogue discovers and keeps track of available IoT resources in the network. It provides REST-based interfaces to select and retrieve data about IoT resources and their services. The participants had to use these interfaces for acquiring information about IoT resources, such as states and the existence of services of a given resource. After that, the participants had to do similar tasks, now using the IoT resource catalogue Browser, a graphical tool that utilizes the REST APIs. Finally, the participants were asked to generate the code stubs for a new IoT resource, using the IoT resource builder tool. • Context manager: The context manager facilitates the management of context as well as sensor fusion. For the evaluation task, some initial contexts and fusions were put to the system. The participants were then asked to add more. In particular they had to add two new different presence sensors to the context. Afterwards, they had to create a fusion out of the sensors and finally, rule to switch a light on, on basis of the fused data, should be defined. • Mixed Criticality Resource Management: The mixed criticality evaluation tested both aspects of the IMPReSS Mixed Criticality Resource Management Tool, the application-level and the device-level mixed criticality. For the application-level mixed criticality, the participants should first acquire knowledge about the system by checking properties of some entities. For instance, they had to find out which IoT resource is associated to a specific server or which application is using a particular resource at the moment. Another task asked for the criticality level of a certain application. As next step, the participants should investigate what happens if they increase the criticality level of one app (the app takes over control of another app with now lower criticality). Using that knowledge, the participants had to change the criticality level of one system so that is takes control of lights. For the device-level mixed criticality, the participants were asked to change criticality levels of resources and observe how that influences a power outage scenario. In this scenario, a long-lasting power outage occurs and devices are switched off after a certain time based on their criticality. 6.3. Usability results The results were interpreted using the analysis tools provided by the UEQ and taking the complexity of the task and the component into account. The raw results for the full IMPReSS SDP in the six dimensions are illustrated in Fig. 13 on a scale from –3 to +3. On the questionnaire –3 represents the most negative answer, 0 a neutral answer, and +3 the most positive answer. Since the different items in the UEQ questionnaires have slightly different personal significance for the respondents, the UEQ toolset provides a benchmarking dataset that allows us to classify our raw data against a set of similar evaluations. This data set contains data from 4818 persons from 163 studies concerning different products (business software, web pages, web shops, social networks)5 . Each of the six dimensions are normalised on a

5

UEQ Data Analysis Tool

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM 14

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

Fig. 13. IMPReSS SDP usability results.

Fig. 14. IMPReSS benchmark usability results.

scale from 0 to 2.5. When compared with the benchmark data, our scores can be classified between “Bad” (in the range of the 25% worst results) and “Excellent” (in the range of the 10% best results) as shown in Fig. 14. For example it appears that a raw score between 1.0 and 1.4 is “Good” in the Novelty dimension, whereas for Attractiveness it has to be in the range of 1.5 to 1.6 in order to be classified as “Good”. As can be noticed, the result is quite satisfactory as all of the six dimensions received the score “Good” or “Excellent”. Four of six dimensions were evaluated as “Excellent” (Attractiveness, Efficiency, Dependability, and Stimulation) with Stimulation being by far the highest score. Novelty, which received the lowest raw score for the individual tools, still lies within the “Good” range of benchmarked scores. The five individual tools also received positive scores for all of the six dimensions. Like the full IMPReSS SDP, the top three dimensions for the individual tools were Attractiveness, Efficiency and Stimulation. However, there is a difference within this top three, namely that while the IMPReSS SDP got the highest score for Stimulation, the average score for Efficiency was the highest for the five components. The Efficiency score was the highest for the Mixed Criticality Resource Management tool, the Application Description Generator tool and the Context Manager tool, all in the range of “Good” and “Excellent”. On average, the Novelty dimension got the lowest score of the six dimensions for both the IMPReSS SDP and the individual tools. The IoT Resource Catalogue, the Application Description Generator, and the Context Manager got the lowest score for Novelty; however, the scores were still in the positive range. Two tools, the RAI and the Mixed Criticality Resource Management tool, scored “Good” and “Excellent” for all six dimensions; the Mixed Criticality Resource Management tool received the overall best score of the five evaluated tools. The Application Description Generator tool got “Good” and “Excellent” scores for five dimensions but got the lowest score for Novelty dimension out of all of the five tools. In conclusion, IMPReSS received a positive usability evaluation, both for the individual components and for the full SPD, which confirms that the IMPReSS SDP offers application developers easyto-use tools for developing smart city applications.

7. Performance analysis A testbed was deployed to evaluate the performance of the proposed solution, in terms of scalability, for evaluating the number of simultaneous active resources IMPReSS can handle, configure and manage through the XMPP-based Communication Manager and Network Manager infrastructure. The RAI API exposes each component (i.e. sensors and actuators) to the infrastructure as a XMPP user/client, named and addressed by the so-called Jabber Identifiers (jID) and served by the open-source Openfire6 XMPP server. In order to simulate sensors and actuators abstracted by RAI we used Tsung7 , an open-source distributed load-testing tool that supports multiple protocols. Tsung was used to perform load and stress testing of Openfire server simulating thousands of resources contemporarily available to the platform. The experiments consisted of two machines with low processing power (1 GB RAM, Atom N570 - 1.66 GHz) for hosting Openfire and Tsung. The maximum number of resources was set to 50 0 0 with rate varying up to about 50 resources per second. In 5 min of simulation time, it has been simulated churn (i.e., random resource arrival/departure), resource faults, and data transmission even under security encryption using Transport Layer Security (TLS) protocol. We measured four key metrics: 1. Request response time: response time for each request (e.g. data resource configuration, resource polling, status changing); 2. Page response time: response time for each set of requests (a page is a group of request not separated by a think time; 3. Connection establishment time: time taken for a connection to be established; 4. Resources throughput: rate of resources per second the system was able to transfer, for the three other metrics above. Table 3 shows the results of the performance analysis. Connect count is exactly 50 0 0, which means that no reconnection try was needed. The XMPP server was loaded with connection requests towards a mean rate of 16.24 resources/s to a maximum 45.8 resources/s each making an average of 65.41 requests per second

6 7

http://www.igniterealtime.org/projects/openfire http://tsung.erlang-projects.org

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

ARTICLE IN PRESS

JID: COMCOM

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

15

Table 3 Scalability of the communication manager. Metric

Maximum (s)

Minimum (s)

Mean (s)

Highest Rate (Resources/s)

Mean Rate (Resources/s)

Count

Request Page Connection

8.66 13.73 0.03225

0.39 0.0 0 0 069 0.00581

3.56 4.27 0.01679

251 /s 175.9 /s 45.8 /s

65.41 /s 57.86 /s 16.24 /s

20,0 0 0 16,919 50 0 0

Fig. 15. Simultaneous users connected to the communication manager.

simultaneously. The response time did not increase significantly when different types of requests were grouped into a page. On the other hand, Fig. 15 shows that we were able to connect 50 0 0 simultaneous users (devices) within 110 s, with a relatively poor hardware architecture. In this way, everyone can run its instance of the system, without the need to do big investments. Furthermore, the solution proposed can scale easily, in different ways: a) upgrading the hardware; b) clustering multiple XMPP servers; c) leveraging the federation features of XMPP, which allows managing the users connected to several XMPP servers, as connected to an unique instance. By running Openfire as a cluster, the load can be distributed among several servers, while also providing failover in the event that one of your servers fails. 8. Conclusions Public buildings consume a considerably high percentage of energy produced in industrialized countries and therefore building management systems have to carefully address the issue of reducing energy usage. The Internet of Things (IoT) may play an important role in the development of new context-aware mixedcriticality management applications that adapt system behavior according to environment changes and deal with real-time demands for prioritizing mission critical equipment and systems. Still, the development of IoT–enabled applications requires specific expertise and poses a burden on developers, due to the lack of proper generic tools. We built a Systems Development Platform (SDP) for enabling rapid development of the context-aware mixedcriticality IoT–enabled applications, mainly for energy-efficiency management in public smart buildings, with the IMPReSS project. IMPReSS is made up of a variety of components for making easier the task of developing IoT-enabled applications. The effectiveness of the SDP for the development of IoTbased context-aware and mixed-criticality applications was assessed by means of using it in four scenarios involving energy efficiency management in public buildings: an efficiency contextaware automated lighting and temperature control application, an application-level mixed-criticality alarm system, an energy con-

sumption monitoring system in a public historic theatre, and a power outage handling system in a university campus. Also, the SDP was evaluated by potential application developers to understand their perception of five key tools of the SDP with regard to usability, related to attractiveness, efficiency, perspicuity, dependability, stimulation and novelty. All five tools received positive scores by the participants, which qualify them as good and excellent according to a well-known user evaluation method. As future work, we aim at extending key features of individual IMPReSS components, as well as deepening their integration for maximizing the synergies that may be obtained from the SDP. Also, we intend to improve the user interaction features in the graphical interfaces, in such a way as to make it clearer to users that the IMPReSS SDP may help them in streamlining the development of IoT-enabled applications. Acknowledgements This research was supported by the European Commission and CNPq within the IMPReSS project (project No. 614100). References [1] L. Atzoria, A. Ierab, G. Morabitoc, The Internet of Things: a survey, Comput. Netw. 54 (15) (October 2010) 2787–2805. [2] B. Balajiy, C. Vermay, B. Narayanaswamyy, Y. Agarwalz, Zodiac: organizing large deployment of sensors to create reusable applications for buildings, 2nd ACM International Conference on Embedded Systems for Energy-Efficient Built Environments (BuildSys 2015), 2015. [3] M. Baldauf, S. Dustdar, F. Rosenberg, A survey on context-aware systems, Int., J. Ad Hoc Ubiquitous Comput. 2 (4) (2007). [4] L. Bass, R. Clements, in: Software Architecture In Practice, Third Edition, Addison-Wesley, Boston, 2012, pp. 21–24. [5] A. Bassi, M. Bauer, M. Fiedler, T. Kramp, R. van Kranenburg, S. Lange, S. Meissner, Enabling Things to Talk: Designing IoT Solutions with the IoT Architectural Reference Model, Springer, 2013. [6] T. Berners-Lee, J. Hendler, O. Lassila, The semantic web, Sci. Am. (May 2001) 28–37. [7] A. Bhattacharya, D. Hong, D. Culler, J. Ortiz, K. Whitehouse, E. Wu, Automated metadata construction to support portable building applications, 2nd ACM International Conference on Embedded Systems for Energy-Efficient Built Environments (BuildSys 2015), November 2015.

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014

JID: COMCOM 16

ARTICLE IN PRESS

[m5G;October 10, 2016;16:19]

C. Kamienski et al. / Computer Communications 000 (2016) 1–16

[8] A. Burns, R. Davis, Mixed Criticality Systems - A Review, University of York, 2016 Technical Report. [9] B. Campbell, P. Dutta, An energy-harvesting sensor architecture and toolkit for building monitoring and event detection, 1st ACM International Conference on Embedded Systems For Energy-Efficient Buildings (BuildSys 2014), 2014. [10] D. Conzon, T. Bolognesi, P. Brizzi, A. Lotito, R. Tomasi, M.A. Spirito, The VIRTUS middleware: an XMPP based architecture for secure IoT communications, 21st International Conference on Computer Communications and Networks (ICCCN 2012), 2012. [11] G. Cugola, A. Margara, Processing flows of information: from data stream to complex event processing, ACM Comput. Surv. 44 (June(3)) (2012). [12] M. Eisenhauer, P. Rosengren, P. Antolin, Hydra: a development platform for integrating wireless devices and sensors into ambient intelligence systems, Internet Things (January 2010) 367–373. [13] Energy.gov, Building Energy Data Exchange Specification Scoping Report, US Department of Energy, Stakeholder & Technology Review, August 2013. [14] EPEC, Guidance on Energy Efficiency in Public Buildings, European PPP Expertise Centre (EPEC), May 2012. [15] Espertech, “Esper complex event processing for Java” Accessed July 15, 2016. http://www.espertech.com/esper/bout_esper_java.php. [16] European Commission, Energy efficiency plan 2011, Communication from the Commission, COM(2011) 109 final, March 2011. [17] European Commission, EUROPE 2020: a strategy for smart, sustainable and inclusive growth, Communication from the Commission, COM(2010) 2020 final, March 2010. [18] E. Ferrera, D. Conzon, P. Brizzi, L. Gomes, M. Jentsch, P. Kool, XMPP-based network management infrastructure for agile IoT application deployment and configuration, Conference on Innovations in Clouds, Internet and Networks (ICIN 2016), March 2016. [19] I. Fette, A. Melnikov, The WebSocket protocol, IETF RFC 6455, December 2011.

[20] B. Hailpern, P. Tarr, Model-driven development: the good, the bad, and the ugly, IBM Syst. J. 45 (3) (2006) 451–461. [21] C. Kamienski, F. Borelli, G. Biondi, W. Rosa, I. Pinheiro, I. Zyrianoff, D. Sadok, F. Pramudianto, Context-aware energy efficiency management for smart buildings, IEEE World Forum on Internet of Things (WF-IoT 2015), December 2015. [22] B. Laugwitz, T. Held, M. Schrepp, Construction and evaluation of a user experience questionnaire, in: 4th Symposium of the Workgroup Human-Computer Interaction and Usability Engineering of the Austrian-Computer-Society, Springer, 2008, pp. 63–76. [23] C. Perera, A. Zaslavsky, P. Christen, D. Georgakopoulos, Context aware computing for the Internet of Things: a survey, IEEE Commun. Surv. Tut. 16 (1) (2014) First Quarter. [24] T. Portela, J. Lafay, Energy efficiency in Brazil: policies, motivators, barriers, International Conference on Renewable Energies and Power Quality (ICREPQ’15), March 2015. [25] F. Pramudianto, C. Kamienski, E. Souto, F. Borelli, L. Gomes, D. Sadok, M. Jarke, IoT Link: An Internet of Things Prototyping Toolkit, IEEE 11th Conference on Ubiquitous Intelligence & Computing (UIC 2014), December 2014. [26] M. Razzaque, M. Milojevic-Jevric, A. Palade, S. Clarke, Middleware for Internet of Things: a survey, IEEE Internet of Things J. 3 (February(1)) (2016). [27] A Schumann, J. Ploennigs, B. Gorman, Towards automating the deployment of energy saving approaches in buildings, 1st ACM International Conference on Embedded Systems For Energy-Efficient Buildings (BuildSys 2014), November 2014. [28] Z. Song, M. Lazarescu, R. Tomasi, L. Lavagno, M. Spirito, High-level Internet of Things applications development using wireless sensor networks, in: Internet of Things: Challenges and Opportunities, Springer, January 2014, pp. 75–109. [29] J. Takalo-Mattila, J. Kiljander, F. Pramudianto, E. Ferrera, Architecture for mixed criticality resource management in Internet of Things, TRON Symposium, December 2014.

Please cite this article as: C. Kamienski et al., Application development for the Internet of Things: A context-aware mixed criticality systems development platform, Computer Communications (2016), http://dx.doi.org/10.1016/j.comcom.2016.09.014