Middleware Architecture for the Internet of Things
KAJSA ELFSTRÖM
Tritech Technology AB Industrial supervisor: Mats Malmberg
Evaluation of IoTivity: A Middleware Architecture for the Internet of Things
Utvärdering av IoTivity: En Mellanvaruarkitektur för Sakernas Internet
KAJSA ELFSTRÖM Examiner: Mark T. Smith KTH Supervisor: Kalle Ngo KTH School of Information and Communication Technology
Today the Internet of Things (IoT) lacks universal standards for communication and interaction between devices. There is a wide collection of diverse software architectures for IoT applications on the market, where smart devices from different manufacturers are often unable to interact with each other.
A standards organization within IoT gaining recognition is the Open Connec- tivity Foundation (OCF), an industry group delivering an IoT software framework specification and a product certification program. Open Connectivity Foundation (OCF) is funding an open source reference implementation of the specification called IoTivity, which runs as middleware intended to be portable to all operating systems and connectivity platforms. The goal of the OCF is to enable interoperability be- tween IoT devices regardless of manufacturer, operating system, chipset or physical transport.
Through a literature review, the key functional and non-functional requirements for IoT middleware architectures were found. Functionality requirements identi- fied were data management, resource management, resource discovery, and context- awareness. The quality attributes were found to be interoperability, adaptability, scalability, security, and real-time behavior.
In this thesis project, IoTivity was evaluated with respect to these requirements with the scenario-based Method for Evaluating Middleware Architectures (MEMS).
As a part of MEMS, a case study of implementing a building management system (BMS) with IoTivity was conducted.
Results showed that, within the framework of the case study, IoTivity complied with three out of four functional requirements, and three out of five quality require- ments identified for IoT middleware architectures. One of the quality requirements, security, was not evaluated in this study.
Keywords: Internet of Things, IoTivity, Middleware, Open Connectivity Foun- dation, Standard.
Idag finns det redan många olika mjukvaruarkitekturer för sakernas internet, på engelska Internet of Things (IoT), ute på marknaden. Ett problem är att det ännu inte finns några brett accepterade standarder för hur dessa saker ska interagera. Det kan ofta innebära att uppkopplade enheter från olika tillverkare inte fungerar ihop.
Det finns ett flertal organisationer som försöker etablera standarder för saker- nas internet, på alla olika nivåer i kommunikationskedjan. En av de organisationer som nämns allt oftare är Open Connectivity Foundation (OCF). Det är en grupp av ledande företag som har specificerat ett mjukvaruramverk för IoT och ett tillhörande program för produktcertifiering. De sponsrar även en referensimplementation av detta ramverk med öppen källkod som kallas IoTivity. Denna referensimplementa- tion körs som en mellanvara och är tänkt att vara portabel till flera olika mjuk- och hårdvaruplattformar. OCFs långsiktiga mål är att möjliggöra kommunikation mel- lan uppkopplade enheter oberoende av deras tillverkare, operativsystem, chip-set och kommunikationsteknik.
Genom en studie av tidigare forskning kunde de mest väsentliga funktionella och kvalitativa kraven på IoT-mellanvara sammanställas. Bland de funktionella kraven fanns datahantering, resurshantering, kontextmedvetenhet och mekanismer för att upptäcka enheter i nätverket. De kvalitativa kraven inkluderade interoperabilitet, anpassningsbarhet, skalbarhet, säkerhet och realtidsbeteende.
Examensarbetet har utvärderat IoTivity med avseende på ovan nämnda krav genom en scenariobaserad evalueringsmetod kallad Method for Evaluating Middle- ware Architectures (MEMS). Som en del av MEMS genomfördes en fallstudie där en systemprototyp för fastighetsautomation implementerades med IoTivity.
Resultat från genomförda experiment visade att, inom ramarna för fallstudien, kunde IoTivity uppfylla tre av de fyra funktionella kraven och tre av de fem kval- itativa kraven. Ett av de kvalitativa kraven, säkerhet, utvärderades inte i det här projektet.
Nyckelord: Sakernas Internet, IoTivity, Mellanvara, Open Connectivity Founda- tion, Standard.
I would like to express my thanks to my examiner Mark Smith, and supervisors Kalle Ngo and Mats Malmberg, for your helpful feedback and inspiration.
To all colleagues at Tritech, thank you for welcoming me with open arms and making the time of this thesis project fun and memorable.
I also wish to extend my thanks to my family for their support and encourage- ment during these past years of studying at KTH.
Kajsa Elfström, Stockholm, April 2017
List of Figures i
List of Tables iv
Acronyms vii
1 Introduction 1
1.1 Background . . . 1
1.1.1 Middleware for the Internet of Things . . . 2
1.1.2 Design Patterns for the Internet of Things . . . 2
1.2 Problem . . . 3
1.3 Purpose . . . 4
1.4 Goals . . . 4
1.5 Benefits, Ethics and Sustainability . . . 4
1.6 Method . . . 5
1.7 Delimitations . . . 5
1.8 Outline . . . 6
2 Theoretical Background 7 2.1 Common Concepts of the Internet of Things . . . 7
2.1.1 Communication Models . . . 8
2.1.2 Internet of Things Stack . . . 9
2.2 Middleware for the Internet of Things . . . 10
2.2.1 Motivation of a Middleware Solution . . . 10
2.2.2 Functional Requirements . . . 11
2.2.3 Non-Functional Requirements . . . 13
2.3 Open Connectivity Foundation and IoTivity . . . 15
2.3.1 The Open Connectivity Foundation Framework . . . 16
2.3.2 IoTivity . . . 16
2.3.3 Architecture Overview . . . 16
2.3.4 Core Framework . . . 17
2.3.5 Architectural Design Patterns . . . 21
2.4 Summary of Related Work . . . 27
3 Methodology 29
3.1 Method for Evaluating Middleware Architectures . . . 29
3.1.1 Description and Motivation . . . 29
3.1.2 Motivating a Case Study in MEMS . . . 29
3.1.3 Steps of MEMS . . . 30
3.2 Equipment for System Prototype . . . 32
4 Case Study 33 4.1 Case Scenario . . . 33
4.1.1 Fictional Project . . . 33
4.1.2 Building Management System . . . 34
4.1.3 Automatic Monitoring and Control Applications . . . 36
4.2 Prototype . . . 37
4.2.1 Building Lighting System Device . . . 38
4.2.2 Emergency Evacuation System Device . . . 38
4.2.3 Entrance Security System Device . . . 39
4.2.4 HVAC System Device . . . 39
5 Evaluation Plan 41 5.1 Key scenarios . . . 41
5.2 Testbed Components . . . 50
5.3 Procedures for Interoperability Experiments . . . 52
5.4 Procedures for Adaptability Experiments . . . 53
5.5 Procedures for Scalability Experiments . . . 53
6 Results 57 6.1 Results of Experiments Testing Interoperability . . . 57
6.2 Results of Experiments Testing Adaptability . . . 57
6.3 Results of Experiments Testing Scalability . . . 59
7 Discussion 65 7.1 Discussion . . . 65
7.1.1 Key Findings from Experiment Results . . . 65
7.1.2 Validity of Experiments . . . 69
7.1.3 Influence of Design Patterns . . . 71
7.1.4 Further Reflections on Quality Requirements . . . 73
7.2 Conclusions . . . 74
7.3 Recommendations for Future Work . . . 75
Bibliography 75
A Resource Type Definitions of Building Management System I A.1 Property Definitions for Single Resource Types . . . I A.1.1 Air Quality Sensor . . . I A.1.2 Alarm . . . II A.1.3 Door . . . II A.1.4 Door Lock . . . II
A.1.5 Elevator Control . . . II A.1.6 Light Source . . . III A.1.7 Location . . . III A.1.8 Mode . . . III A.1.9 Motion Detector . . . III A.1.10 Operational State . . . IV A.1.11 Smoke Detector . . . IV A.1.12 Surveillance Camera . . . IV A.1.13 Temperature . . . IV A.1.14 Thermostat . . . V A.1.15 Time Interval . . . V A.1.16 Ventilation . . . V A.2 Required Resource Links of Collection Resource Types . . . VI A.3 Resource Type and Interface Definitions . . . VII B Modification of Server Application Source Code in Key Scenarios
8 to 10 IX
2.1 An overview of communication models for the Internet of Things (adapted from figures of [1]). . . 8 2.2 An example of an Internet of Things stack. . . 10 2.3 The functional blocks of the OCF framework architecture (adapted
from Figure 2 of [2]). . . 17 2.4 The concepts of entity, resource, URI, property, and representation
in the OCF resource model. . . 18 2.5 An example illustrating the concepts of collection and link in the OCF
resource model. . . 19 2.6 The five steps of the observe mechanism in the OCF framework
(adapted from Figure 32 of [2]). . . 24 2.7 Communication for resource directory discovery and for resource di-
rectory supported discovery queries (adapted from Figure 30 of [2]). . 26 4.1 Overview of building for which building management system proto-
type was implemented. . . 34 4.2 Overview of communication in building management system. . . 36 4.3 An overview of the network setup for the building management system
prototype. . . 37 5.1 A utility tree for organizing quality attributes, sub-concerns, and key
scenarios for the evaluation. . . 43 6.1 A line chart showing resource request delay times in scenarios 12.1,
12.2, and 17. A marker represents the average value of the sample subset with larger, unexpected values. Error bars show standard deviation from the mean. . . 60 6.2 A line chart showing resource request delay times in scenario 12.3. A
marker represents the average value of the sample subset with larger, unexpected values. Error bars show standard deviation from the mean. 61 6.3 A line chart showing how the round-trip delay time per request changes
with the number of requested resources in key scenarios 12.1 and 12.2.
Error bars show standard deviation from the mean. . . 62
6.4 A line chart showing how the one-way delay time per request changes with the number of requested resources in key scenarios 12.3 and 13.
Error bars show standard deviation from the mean. . . 62 6.5 A line chart showing how the round-trip delay time per resource
changes with the number of requested resources in key scenario 17, comparing results for low and high quality of service (QoS). Error bars show standard deviation from the mean. . . 63
2.1 An example of properties of a light resource represented with the
OCF resource model (adapted from Table 30 in [2]). . . 20
2.2 A table presenting some of the standard resource interfaces defined in the OCF framework (adapted from Table 8 in [2]). . . 20
3.1 Device platforms used in test environment for building management system prototype. . . 32
4.1 Resources and applications in building management system prototype. 35 5.1 Key Scenario 1 . . . 44
5.2 Key Scenario 2 . . . 44
5.3 Key Scenario 3 . . . 44
5.4 Key Scenario 4 . . . 45
5.5 Key Scenario 5 . . . 45
5.6 Key Scenario 6 . . . 46
5.7 Key Scenario 7 . . . 46
5.8 Key Scenario 8 . . . 46
5.9 Key Scenario 9 . . . 47
5.10 Key Scenario 10 . . . 47
5.11 Key Scenario 11 . . . 47
5.12 Key Scenario 12 . . . 48
5.13 Key Scenario 13 . . . 48
5.14 Key Scenario 14 . . . 48
5.15 Key Scenario 15 . . . 49
5.16 Key Scenario 16 . . . 49
5.17 Key Scenario 17 . . . 49
5.18 Metrics and scales for key scenarios. . . 50
5.19 Testbed components used in the experiments. . . 51
6.1 Experiment results of interoperability metric: Percentage of requests correctly processed. . . 57
6.2 Experiment results of adaptability metric: Number of logical lines of code (LLOC) added/changed in source files. . . 58
6.3 Experiment results of adaptability metric: Number of source code software modules that required changes. . . 58 6.4 Experiment results of scalability metric: RTD per request decreas-
es/increases as the number of requested resources increases. . . 59 6.5 Experiment results of scalability metric: OWD per request decreas-
es/increases as the number of requested resources increases. . . 59 6.6 Experiment results of scalability metric: Number of requested re-
sources before exceeding 10 sec RTD or OWD. . . 59 A.1 Common properties of all resources. . . I A.2 Air quality sensor resource properties. . . I A.3 Alarm resource properties . . . II A.4 Door resource properties . . . II A.5 Door lock resource properties . . . II A.6 Elevator control resource properties . . . II A.7 Light source resource properties . . . III A.8 Location resource properties . . . III A.9 Mode resource properties . . . III A.10 Smoke detector resource properties . . . III A.11 Operational state resource properties . . . IV A.12 Motion detector resource properties . . . IV A.13 Surveillance camera resource properties. . . IV A.14 Temperature resource properties. . . IV A.15 Thermostat resource properties . . . V A.16 Time interval resource properties . . . V A.17 Ventilation resource properties . . . V A.18 Collection resource type definitions. . . VI A.19 Resource Type and Interface Definitions. . . VII
6LoWPAN IPv6 over Low power Wireless Personal Area Networks ALG Application Layer Gateway
API Application Programming Interface BMS building management system CoAP Constrained Application Protocol
CRUDN Create, Retrieve, Update, Delete, and Notify HATEOAS Hypermedia as the Engine of Application State HTTP Hypertext Transfer Protocol
IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force
IoT Internet of Things IP Internet Protocol
ITU International Telecommunication Union JSON JavaScript Object Notation
LLOC logical lines of code M2M Machine-to-Machine
MEMS Method for Evaluating Middleware Architectures
MQTT Message Queuing Telemetry Transport MQTT-SN MQTT for Sensor Networks
OASIS Advancing Open Standards for the Information Society OCF Open Connectivity Foundation
OIC Open Interconnect Consortium OS operating system
OWD one-way delay time QoS quality of service
RAML RESTful API Modelling Language REST Representational State Transfer ROA Resource-Oriented Architecture RTD round-trip delay time
UDP User Datagram Protocol URI Uniform Resource Identifier URL Uniform Resource Locator XML Extensible Markup Language YAML YAML Ain’t Markup Language
This chapter presents the background and context of the problem area addressed in the thesis. The specific problem, the problem solving approach and delimitations are described, along with the purpose and goals of the project and the written thesis.
A brief discussion of benefits, ethics, and sustainability is given. The chapter ends with an outline of the structure and content of the thesis.
1.1 Background
The Internet of Things (IoT) is expected to deliver a whole new range of services to all parts of our society, and improve the way we work and live. Among the application scenarios for Internet of Things (IoT), we find smart cities, smart cars, home and building automation, smart health care, environmental monitoring, and smart farming.
The challenges within IoT are often related to interoperability, device resource constraints, and security. The highly distributed, ubiquitous and heterogeneous environment of IoT requires a complex and scalable software architecture. Many devices have limited energy, memory, and processing capacities, and commonly face requirements of simplicity and low development and manufacturing costs. Security and privacy are essential for the IoT since a vulnerable network potentially enables unauthorized access to monitoring and control of all sorts of devices in cars, medical equipment, and locking systems. The interoperability issues come with heteroge- neous devices and networks, and the diversity of application domains encompassed by IoT.
According to [3], the best approach to face the above challenges is to use a software platform defined as middleware. Middleware for IoT is an active research area, many have been designed and implemented, and there are various industrial groups suggesting standard specifications for this type of IoT software platform.
However, as noted by [4, 5], there is no middleware available today that can support all the services generally requested in IoT applications.
1.1.1 Middleware for the Internet of Things
Every IoT system has an underlying software architecture consisting of a set of integrated elements, delivering the functionality and quality the system requires.
Middleware refers to a category of software infrastructure technologies that simplify the construction of distributed software architectures.
As defined by [6], middleware is an abstraction layer, hiding the details of the underlying software and hardware. It connects the application layer with underlying layers such as operating system (OS) and device drivers.
The desirable requirements of a middleware architecture, listed by [6], help to explain its purpose. The middleware should preferably
• be adaptable, flexible and scalable to support variations in application-level requirements and variations in resource availability of devices
• provide applications with secure access to resources on remote devices
• be portable to different hardware and software platforms
• support various application programming languages
• provide standardized and easy-to-use communication interfaces abstracted to such a level that applications can seamlessly communicate with remote devices There can be various levels of middleware in a software architecture. However, as clarified by [6], middleware resides in the layer which is not an OS or device drivers, nor an application.
Within the context of IoT, the first essential role of middleware is to provide abstraction from the physical things, that is, objects of the physical world, to the applications. The second is to provide interoperability across heterogeneous devices and diverse application domains. Other main features proposed in [3] are context awareness, handling of large data volumes, privacy and security, and device discovery and management.
Several systematic reviews of existing middleware approaches for the IoT have been undertaken, such as [3], [4], and [5, Chapter 4]. An overview of commercial IoT frameworks is presented by [7].
1.1.2 Design Patterns for the Internet of Things
The IoT concept presents a wide range of design problems at many levels of the system architecture. The application domains, use cases and resource constraints are many and varied. In order to avoid reinventing the wheel, and in order to deliver a high-quality architecture, software developers use design patterns.
Within software engineering, a design pattern is a reusable solution to a reoc- curring design problem within a particular context. It describes a best-practice, or a known and proven approach, to solve a common problem when designing soft- ware. Each pattern applicable to a given problem has advantages and disadvantages depending on contextual factors.
Design patterns can be seen as building blocks of a software architecture. A set of coherent design patterns can form a reference architecture from which a system’s behavior can be modeled and understood.
There are various design patterns relevant for IoT middleware such as informa- tion models, interaction models, and infrastructure models. Using a middleware, providing an abstract representation of physical things and enabling applications to interact with them, is a sort of high-level design pattern in itself.
Information models can describe how to structure data, for instance in an XML document, or define models for resource access control. Design patterns for interac- tion can describe how different system components communicate with each other.
An example is the publish-subscribe communication pattern, and the use of a mes- sage broker to connect the publishers and subscribers.
Design patterns that can use well known standards and practices for communi- cation are advantageous since they promote interoperability.
1.2 Problem
Today the IoT lacks universal standards for communication and interaction between devices. This has resulted in a wide collection of diverse software architectures for IoT applications on the market, where smart devices from different manufacturers are often unable to interact with each other. The difficulty of interaction is increased by device heterogeneity in terms of hardware platform and underlying software, communication protocol and technology, and data models. The resource constraints imposed upon devices in many IoT application scenarios require resource efficient solutions, limiting the choice of standards and protocols to use.
Various standards organizations try to overcome these problems and promote technological advance by suggesting common standards for IoT software architec- tures. One of the organizations contributing in the IoT standardization effort is the Open Connectivity Foundation (OCF), an industry group delivering an IoT software framework specification and a product certification program. The organization is including in its membership well-known companies such as Intel, Cisco, General Electric, Samsung, Microsoft, Qualcomm, and IBM. Open Connectivity Foundation (OCF) further sponsors an open source reference implementation of the architecture specification called IoTivity, which runs as middleware intended to be portable to all operating systems and connectivity platforms. Initially OCF has focused on smart homes and offices, but targets various application domains in the future. The goal of the OCF is to enable devices to communicate regardless of manufacturer, operating system, chipset or physical transport [8].
In relation to the above problem area, the research question was:
• In a building management system context, how well does IoTivity meet the key functional and quality requirements identified for IoT middleware?
1.3 Purpose
The purpose of this project was to evaluate IoTivity, an open-source reference im- plementation of the IoT architecture specification from OCF. The evaluation was performed with regard to the quality and functionality generally required from IoT middleware and applications. The purpose of this thesis was to describe the gen- eral requirements of IoT middleware, discuss the selection of design patterns for the middleware architecture presented in the OCF framework, and present a case study of using the IoTivity middleware in a building management application scenario.
1.4 Goals
This thesis project had the following goals:
• Identify and describe the key functional and quality requirements of IoT mid- dleware through a literature study
• Identify and describe the key design patterns forming the IoTivity middleware architecture described in the OCF framework specification
• Prototype a building management system (BMS) using IoTivity, and evaluate the functionality with regard to the identified quality attributes by performing experiments on the system prototype
• Analyze how the key design patterns of IoTivity affected the behaviour of the system in the experiments
1.5 Benefits, Ethics and Sustainability
This project could contribute in the effort to find common communication and interoperability solutions for the IoT. With common standards the infrastructure technology for the IoT can mature and become more reliable. Interoperability and possibility to integrate smart devices from different manufacturers will protect users from being dependent upon a single vendor.
The reference implementation of the OCF framework is open source, meaning the source code is made available to anyone wishing to study it, change it and distribute it. It is developed in a collaborative manner, bringing in ideas and per- spectives from developers from various companies, industry sectors, and interest groups. Sharing knowledge and solutions as in the open-source development model can advance technology and provide innovation opportunities.
There are various ethical issues arising with the IoT, especially regarding privacy and integrity. The IoT applications collect and make use of large amounts of data about the surrounding world, including people. The predicted social benefits of IoT applications such as smart cities, offices and health care include improved efficiency, health, and safety. At the same time, the extensive data collection implies a risk of potential breaches of privacy.
1.6 Method
General software architecture evaluation methods commonly focus on understanding the connection between the architecture design and the selected quality attributes.
The evaluator wants to ensure that the architecture meets the key quality goals while supporting the key functional requirements.
As described by [9], there are particular concerns that come into the picture when evaluating middleware architecture. Middleware is usually designed to support a wide range of applications, as in the case with IoTivity. Since it is meant to be reusable over several vertical domains, it is said to be horizontal in nature. The key quality attributes, however, can have different scope and importance when related to a particular vertical domain or application context.
In this project, the scenario-based Method for Evaluating Middleware Architec- tures (MEMS) [9, 10] was applied in order to evaluate IoTivity. As a part of this method, a case study of implementing a building management system (BMS) pro- totype was conducted. The idea of MEMS is to express the quality attributes in the form of scenarios, since the attributes themselves are too vague to analyze. A scenario describes an action or a chain of actions happening in a system when a cer- tain architecture is used. The scenario should be quality-sensitive since it is meant to show how the architecture responds with respect to the given quality attributes in a particular context.
The steps of MEMS include
• determining key quality attributes
• identifying key architectural design patterns
• generating key scenarios
• defining quality metrics and scales
• prototyping
• designing and running experiments measuring the quality of the architecture The project used an inductive research approach, and the middleware was eval- uated exclusively with quantitative metrics. Today there is no broad consensus on what design patterns to use for IoT middleware targeting various vertical domains.
Evaluating one middleware architecture in one vertical domain, in this case BMSs, was a step to find the most suitable design patterns for this type of middleware.
1.7 Delimitations
The complexity of the IoTivity middleware made it impracticable to evaluate the quality of the complete architecture, considering the time limitation of this project.
Therefore, this project evaluated a few of the components considered important for IoT middleware. One important component of the architecture not investigated in this project is security. Provision of secure communication and authorized remote
access of resources is of key importance when evaluating the utility of a middleware solution.
In the quality evaluation of the IoTivity middleware only quantitative metrics were applied, since qualitative metrics would have required developers or other stake- holders to subjectively assess the quality, which was outside the scope of this explo- ration. Using both quantitative and qualitative metrics could have provided a more complete picture.
1.8 Outline
The overall structure of the study takes the form of seven chapters. Chapter Two begins by laying out the theoretical framework of the research, and looks at com- mon concepts of IoT, the requirements of IoT middleware, the core architecture and identified design patterns in the OCF framework specification. The third chapter is concerned with the methodology used for this study. MEMS and the case study are motivated, and the steps of MEMS are explained. The thesis goes on describing the case study in depth in chapter four, and the plan for the evaluation in chapter five, including a description of the test environment and the experiment procedures.
Chapter six presents the experiment results with text, tables, and graphs, without any interpretation. The seventh and last chapter presents the findings and con- clusions of the research, discusses the results analysis, and provide suggestions for future work.
This chapter presents the theoretical background of this thesis project. The initial section describes the common concepts of and models for the Internet of Things (IoT), generating the functional requirements and quality considerations for an IoT software architecture. Then follows a section motivating a middleware solution, and describing the identified key requirements of such an approach. The third section describes the OCF framework, their reference implementation IoTivity, its core functional blocks, and key design patterns. The chapter concludes with a summary of previous work and how it relates to this project.
2.1 Common Concepts of the Internet of Things
Although the term Internet of Things (IoT) is widely used, and various definitions of the term have been proposed, there is still no common agreement of what the term actually encompasses. One of the more comprehensive and general definitions of Internet of Things (IoT), as well as other terms commonly used within IoT, are suggested by the International Telecommunication Union (ITU) [11].
Internet of Things: A global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies.
Thing: With regard to the Internet of things, this is an object of the physical world (physical things) or the information world (virtual things), which is capable of being identified and integrated into communication networks.
Device: With regard to the Internet of things, this is a piece of equipment with the mandatory capabilities of communication and the optional capabilities of sensing, actuation, data capture, data storage and data processing.
The following subsections describe some of the common concepts and views of IoT, such as communication models, protocols and networking technologies commonly used.
2.1.1 Communication Models
In an overview of IoT presented by [1], four different device communication models are described. These are the device-to-device, device-to-cloud, device-to-gateway, and back-end data-sharing models, shown in Figure 2.1. The communication and networking protocols in the figure are only examples of what can be used.
The device-to-device model includes two or more devices exchanging messages directly, which is a common communication model in home automation applications.
This requires the devices to have the same communication protocol and data model.
In the device-to-cloud model, the devices connect directly to an Internet cloud service. The cloud connection enables a user to access the device remotely via a Web interface or smartphone. The devices usually exploit traditional communication mechanisms such as Ethernet or WiFi to establish the connection to the IP network.
Many vendors use proprietary data protocols for communication device-to-device and device-to-cloud, which forces users to buy devices exclusively from the same product family, commonly referred to as vendor lock-in.
Figure 2.1: An overview of communication models for the Internet of Things (adapted from figures of [1]).
The device-to-gateway model displays how an IoT device connects to a cloud service via an Application Layer Gateway (ALG). The ALG, acting as an interme- diary, can provide services like security and data protocol translation, and is often used to address interoperability issues between devices with otherwise incompatible communication technologies. In a smart home scenario, the gateway is commonly a smartphone or a smart hub.
The back-end data-sharing model is an extension of the device-to-cloud model, with the aim to avoid data silos when IoT devices upload data only to a single server.
The idea is to enable the server to share the data with other back-end systems, so that data streams from several IoT devices can be aggregated and analyzed. This model targets interoperability between back-end systems, but is difficult to realize without common standard communication and data protocols between the vendors.
In summary, these models are strongly influenced by the vendors’ choice of using open standard or proprietary protocols. The device-to-gateway model’s primary use is to enable interoperability, while the back-end data-sharing model requires it [1].
2.1.2 Internet of Things Stack
There are many standards and protocols that are relevant for and typically used within IoT. Figure 2.2 shows some of the protocols commonly used to enable con- nectivity and communication between IoT devices. There is no common standard IoT stack model, so the stack layer names on the left side in Figure 2.2 are only there for guidance.
Starting from below in Figure 2.2, IEEE 802.15.4 [12] is a standard for low-rate wireless networks, from the Institute of Electrical and Electronics Engineers (IEEE).
It defines physical layer and media access control sublayer specifications and aims to provide low power, low cost, low complexity, and low data rate connectivity for non-expensive devices. The standard has multiple physical layer specifications in order for support of various frequency bands. Several protocol specifications like 6LoWPAN, Zigbee [13], Z-Wave [14], and Thread [15] are based on IEEE standard 802.15.4.
6LoWPAN is the name of an Internet Engineering Task Force (IETF) working group and the acronym stands for IPv6 over Low power Wireless Personal Area Networks. This working group is defining an adaption layer and specifications for transmitting IPv6 over IEEE 802.15.4 networks [16].
IPv6 is version six of the Internet Protocol (IP), meant to be the successor of IPv4 [17]. The main difference is the expanded addressing capability, increasing the IP address from 32 bits to 128 bits, which is necessary since the Internet is running out of unique IPv4 addresses [1]. Other improvements are header simplification, support for extensions and options, and traffic flow labeling capacity [17]. A challenge is that IPv6 is not compatible with IPv4, and much of the available software for IoT devices today only supports IPv4 [1].
Message Queuing Telemetry Transport (MQTT) is a light-weight publish-subscribe messaging protocol, suitable for IoT connectivity due to its design principles of min- imizing network bandwidth and device resource requirements. Since 2014, MQTT is an Advancing Open Standards for the Information Society (OASIS) standard [18].
There is also an extension, called MQTT for Sensor Networks (MQTT-SN). It is very close to MQTT, but is further optimized for a wireless communication environment with high link failure rate and low bandwidth, and for low-cost, battery-operated devices with restricted storage and processing capabilities [19].
Constrained Application Protocol (CoAP) is another protocol designed for con- strained networks and devices, and suitable for IoT communication. It provides a request-response model based on Representational State Transfer (REST), similar to and easily interfaced with the well-known Hypertext Transfer Protocol (HTTP),
and is thereby easily integrated with the web [20].
MQTT runs over TCP, MQTT-SN runs over UDP, and CoAP runs over both TCP and UDP. All three of them are promising protocols to use with IoT.
In the application layer in Figure 2.2, binary, JSON, and CBOR are listed. These are examples of data formats from the IPSO Smart Objects design pattern. This pattern provides a consistent data model in order to achieve interoperability between smart devices.
Only the protocols from Figure 2.2 with the most significance for IoT have been explained in this text.
Figure 2.2: An example of an Internet of Things stack.
2.2 Middleware for the Internet of Things
This section summarizes and describes the requirements for IoT middleware found in previous research. It does not distinguish requirements specific for building manage- ment applications, but instead describes general requirements for IoT middleware solutions targeting various vertical domains and application scenarios, since that is the overall concern of this thesis project.
2.2.1 Motivation of a Middleware Solution
A middleware solution can ease the application development process by providing an abstraction and adaption layer, hiding the details of diversity of the underlying hardware and software platforms. The middleware can provide Application Pro- gramming Interfaces (APIs) for physical layer communication, offer common ser-
vices to applications, and integrate heterogeneous computing and communication devices [3].
In the light of the characteristics of IoT infrastructures and applications pre- sented in Section 2.1, a middleware platform is a useful approach to cope with the complexity, heterogeneity, connectivity, and scalability challenges encountered in IoT [3, 4].
2.2.2 Functional Requirements
The functional requirements are those describing what the middleware should do and what features it should provide.
Bandyopadhyay et al. [3] have identified six functional blocks required in IoT middleware, being data management, context awareness, resource discovery, re- source management, security and privacy, and interoperation. In this thesis, security and interoperability are considered as non-functional requirements and are described in Section 2.2.3. The functional blocks are described in the following subsections.
Data Management
Data management services usually required by applications are data acquisition, processing, storage and transfer. The processing can include data filtering, com- pression, and aggregation [4].
The data occurring in IoT networks can be sensed data or any information rel- evant for applications such as positional, environmental, identification, or history data. It can also be metadata describing the device context or the network infras- tructure [3].
According to [5], all network devices, be it processing, sensor or actuator nodes, should operate and be configured in the same way. Using the same data management middleware component in all nodes, enabling each node to collect, store, process and send data, will promote interoperability between heterogeneous platforms and provide a homogeneous operation layer for data management.
Regarding constrained devices, there are strategies for easing the burden of data management. If the node has limited storage and processing capabilities, the node can send its data to an assisting node, responsible for processing data and answering queries. If the node has limited power supply, it is often better to perform data processing and aggregation before transfer, since sending large amounts of raw data over a wireless medium, possibly to many receivers, requires more energy than the processing.
Resource Discovery
Resource discovery is about enabling applications to discover what resources or services are available for use in the network.
IoT resources include the resources found in devices, such as their power and memory, their connected sensors and actuators, available communication modules, and services they provide [4].
According to [4], important requirements for the resource discovery mechanism are to be automated and scalable. The article states that, due to the dynamic character of the IoT infrastructure, one must assume that the availability of resources in the network is continuously changing.
In a centralized system, a dedicated server could be responsible for finding devices present in a network, retrieve their metadata and notify applications about available resources or services. In a decentralized approach, each new device should be able to connect to the network, make its presence known and announce the resources or services it offers [4].
The device metadata can include device name, vendor or manufacturer details, and description of underlying software and hardware platform. Then there is the semantic device description, which can describe the available resources or services, device capabilities, security properties or device malfunction. For other devices to understand what to do with this information, the semantic device description must comply with a common semantic model, which should be optimized for resource consumption [3].
Resource Management
A middleware should deliver services for resource consumption and configuration.
Resource management is about managing resource information and providing proper resource access interfaces. Resources should be described, accessed, and configured in a homogeneous manner, even if the devices are heterogeneous [5]. This requires a semantic device description, which abstracts from the specific hardware and software platform of a device, and instead presents its type, properties and features. A device ontology of some sort is commonly used for this purpose [3].
Resource configuration capabilities can include powering up or down a device, managing subscriptions for publish-subscribe messaging, starting or stopping peri- odic activities, managing alarms and events, setting actuation values, monitoring parameters, or any other application-specific setting [5].
Resource management can also be about monitoring resource usage, fair resource allocation and provisioning, and resolving resource conflicts. This is especially im- portant when resources are constrained and impact the quality of service (QoS) of a system [4].
Moreover, resource management can include device status inquiry and device malfunction discovery.
Context Awareness
Xin Li et al. [21] explain the concepts and key features of context awareness, and present a survey of existing context aware middleware technologies. The article claims that if a device is to be smart, it has to be aware. The idea of context awareness is that devices autonomously should be able to adapt their behaviour to the changing environment, and thereby reduce the need of human intervention.
According to [4], context awareness plays an essential role in achieving the vision of IoT, since Machine-to-Machine (M2M) or device-to-device communication is one of the pillars of IoT.
There are ongoing discussions on what context actually means, and several def- initions have been reviewed by [21]. The general definition finally selected by [21]
was "...context is any piece of information that can represent the changes of the circumstance (either static or dynamic)". Examples of context parameters are loca- tion, identity, and state of things or people. It can be the time of the day, season, temperature, or any information used to characterize the situation of things or de- vices.
Furthermore, the most general and accurate definition of the term context aware- ness designated by [21], is "a system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task", which was originally presented by [22].
As described by [21], the IoT has brought about many devices able to collect context information by means of sensors. The challenge now is to find efficient solutions to increase the usability of the context data. Adding context awareness ability to the middleware architecture, enabling context detection and management, decreases the complexity of context aware application development.
Context acquisition, modeling, reasoning, distribution, and visualization are the events of a context lifecycle, according to [21]. Thus, these are the required compo- nents of a context-aware middleware, in one form or another.
2.2.3 Non-Functional Requirements
The non-functional requirements are those describing how the middleware should perform a certain function and what quality attributes it has.
Interoperability, security and privacy, scalability and adaptability are listed as key requirements of IoT middleware in [3, 4, 5]. The importance of timeliness and bounded response times in applications with real-time requirements is noticed by [4, 5]. Additional requirements mentioned in [4] are reliability, ease-of-deployment and popularity. These requirements are described in the following subsections.
Interoperability
Interoperability is about allowing devices to share information despite heterogeneity.
To achieve this, heterogeneous device components must be abstracted and managed in the same way. The middleware should provide all devices with common models for configuration and data processing, as well as standard interfaces for data and resource access [5]. The middleware should run over heterogeneous devices without requiring any additional effort or custom programming from the application devel- oper [4]. Devices should also be able to interact across heterogeneous networks, potentially using different communication technologies or protocols.
Interoperability can be further divided into network, syntax, and semantics [3].
Network interoperability defines the protocols used for exchanging information across the network and covers the basic connectivity issues, though does not consider the content of the information.
The syntactic interoperability considers the encoding format and structure of the data shared between devices. Examples of open standard data interchange formats are JavaScript Object Notation (JSON), Extensible Markup Language (XML), and
YAML Ain’t Markup Language (YAML). Appropriate syntax and data representa- tion are prerequisites to semantic interoperability.
Semantic interoperability requires a semantic model describing how to interpret the information shared between devices, or in other words, how to understand the meaning of the content. The semantic information model is often domain-specific.
Security and Privacy
Security and privacy are critical aspects of IoT, and have to be considered at all system levels and in all middleware components. The key elements to consider are confidentiality, authenticity, and non-repudiation [3].
According to [3], security can be dealt with in two ways. One way is to implement high-level peer-to-peer communication, where peers communicate in a secure and abstract way at higher layers. The other approach is to implement secure topology management, handling authentication of new peers, network access permissions, and protection of routing information exchanged in the network.
Context-aware middleware and applications, introduced in Section 2.2.2, might deal with personal information, such as the health status of a person or location of an object, information which must not be disposed to unauthorized persons or devices. Therefore every component of the middleware using personal information must consider privacy [4].
Real-Time or Timeliness
The real-time or timeliness requirement concerns the ability of the middleware to support applications with real-time constraints. IoT involves many real-time appli- cations within domains such as health care, transportation, and factories [4].
Middleware should provide real-time services to overlying applications, ensuring bounded response times when necessary. In real-time applications, a late delivery of information might make an operation useless or even endanger the system or its users [4]. A real-time operation is correct only if it is performed logically correct and finished within a certain time frame. Timeliness is generally important since much of the information exchanged in a network is only valid and useful for a limited amount of time.
Scalability
The scalability requirement of IoT middleware has two key aspects. The first is the question of resource constrained devices which lack the capability to host a complex middleware architecture supporting every potentially relevant feature for an IoT application. Consequently, the middleware must be modular, so that constrained devices can implement only the most basic functionality required to fulfill its pur- pose. Some devices with very limited resources might even need assistant devices doing the heavy lifting of data storage, processing, aggregation and transfer.
The second is the aspect of extremely large networks of devices, and extremely large volumes of data collected and exchanged by these devices. The middleware
needs a scalable design in order to accommodate the growth of networks and ap- plications [4]. According to [3], managing these voluminous data requires improved methods for finding, fetching, and transferring data, adding new challenges of data querying, indexing, and modeling
IPv6, explained in Section 2.1.2, is part of the answer for a scalable IoT infras- tructure, providing a scalable solution for addressability of devices.
Adaptability
Since the middleware is intended to be reusable for a wide range of application and use scenarios, it must be adaptable to the numerous changes of environment, cir- cumstances and application-level demands occurring within IoT. As noted by [3], the objective of all middleware is to offer an adaption layer in a plug and play mode.
Applications might have diverse demands of what set of operations should be avail- able, what things and concepts should be possible to virtualize, minimum lifetimes, or maximum response times. In order to enable adaption of the middleware even after deployment, it should provide system and resource configuration interfaces, to eliminate the need to reprogram the device [5]. For context-aware applications, the middleware should enable dynamic adaption to changing contexts [4].
More Non-Functional Requirements
Other significant non-functional requirements, although only mentioned by [4] and therefore not considered among the most important in this thesis, are reliability, ease-of-deployment, and popularity [4].
Reliability concerns the middleware’s fault-tolerance, which is the ability of the middleware system to remain operational during the time period of a mission, even if faults occur in one or several components. The system-level reliability applies to all middleware components, since no chain is stronger than its weakest link.
Ease-of-deployment, meaning easy installation and setup of a device, is desirable since the person deploying it should not be required to have expert knowledge.
Popularity refers to the likelihood of continued support, maintenance, and ex- tension of a particular middleware technology, which increases with the number of users, developers, and researchers that adopt it. This is a main concern for embed- ded hardware in general. Often manufactures promise a certain product lifetime with support, hardware availability, and tool chains.
2.3 Open Connectivity Foundation and IoTivity
This section presents the Open Connectivity Foundation (OCF) framework with an overview of the architecture, descriptions of the core functional blocks, and de- scriptions of the identified key architectural design patterns. All information and examples about the OCF framework in this section are extracted from the Open In- terconnect Consortium (OIC) specification version 1.1 [2]. OCF mentions on their web site that this document is still a draft specification and not the final, adopted version.
2.3.1 The Open Connectivity Foundation Framework
Open Connectivity Foundation (OCF) is an industry group and standards organi- zation with the objective of developing standards and certification for IoT devices.
It is one of many competing standards organizations within the IoT domain.
The vision of OCF is that the billions of devices predicted to be connected to the IoT within the next few years should be able to communicate with one another regardless of their manufacturer, vertical market sector, operating system or physical transport technology [8].
The standard specification presented by the OCF is called the OIC specifica- tion, and covers the core architecture, security, resource type models, and so far one vertical market profile which is smart home. The OIC specification has adopted a Resource-Oriented Architecture (ROA), implying that things, information, and concepts are represented as resources. The resource model is meant to be domain- agnostic, and then vertical profiles are provided on top of the core framework, spec- ifying domain-specific semantics. The vertical market profile contains a resource specification, which is a list of reusable resources in, for instance, smart home de- vices. A future goal of OCF is to specify profiles for multiple vertical markets within IoT.
Resources are specified in RESTful API Modelling Language (RAML) and each resource definition contains a unique identifier, an indication whether the resource is an actuator or a sensor or another type, a list of supported methods and a JSON schema for input and output for each method [23].
2.3.2 IoTivity
IoTivity is an open source reference implementation of the OCF standard specifica- tion, although it is not strictly limited to those requirements. It runs as a middleware and aims to provide seamless connectivity device to cloud and device to device. The software framework is licensed under the Apache license version 2.0. As of January 2017, IoTivity is compliant with the OIC specification version 1.1 [24].
2.3.3 Architecture Overview
The OIC architecture is based on the principles of Resource-Oriented Architecture (ROA), and the operations on physical entities should be RESTful, meaning they should comply with the Representational State Transfer (REST) architecture style.
OCF aims to provide a framework for communication and interoperability, adapt- able to various IoT market segments such as consumer, industry, automotive, and health. Further it should be portable to various hardware platforms, operating systems (OSs), and communication and transport layer technologies.
The architecture is intended to be suitable for constrained as well as resource- rich smart devices. Therefore, OCF has aimed to make it scalable and adaptable to varying device capabilities.
The architecture’s functional blocks required for operation are L2 connectivity, networking, transport, the OIC framework and the application profiles, as shown in Figure 2.3. L2 connectivity refers to functionality required to set up the network
connection on the physical and data link layers. Application profiles contains the data models and functionality required in a specific market segment, such as smart home or smart health.
The specification defines the roles of a server and a client, and interactions be- tween these roles. A server is a device hosting resources, providing resource state information and facilitating remote interaction with these resources. A client is a device accessing a resource on a server.
The OIC framework components are described in the subsequent sections.
Figure 2.3: The functional blocks of the OCF framework architecture (adapted from Figure 2 of [2]).
2.3.4 Core Framework
The core framework consists of Identification and addressing, the Create, Retrieve, Update, Delete, and Notify (CRUDN) operation definitions, Resource model, Mes- saging, Discovery, Device management, and Security components, described below.
This information was found in the OIC specification version 1.1 [2].
Identification and addressing
Identification and addressing defines how to uniquely identify, name and address elements in the network. The identifier must be unique within a context or domain, or guaranteed to be unique across all contexts and domains. Within the private domain, such as a smart home where devices communicate via a gateway, an IP- address could be an identifier. Resources can be identified with a Uniform Resource Identifier (URI), and if the URI is a Uniform Resource Locator (URL), it can also be used for addressing. If a URI is not applicable, the resource may have a property whose value is the resource identifier.
Messaging Operations
CRUDN are the set of operations defined for data and resource management. These operations are performed by clients on resources made available by a server. With
the Create command, a client can request a creation of a new resource instance on a server. The Retrieve command is used for querying the current representation state of a resource. When a client wants to do a partial or complete update of a resource representation, it can use the Update command. The Delete command requests removal of a resource instance. Lastly, the Notify command is used to subscribe to asynchronous notifications whenever a resource state changes.
A middleware messaging component maps the CRUDN operations to a specific communication protocol. In version 1.1. of the OIC specification, it is specified how to map the CRUDN operations to the Get, Post, Put, Delete methods in CoAP.
Resource Model
The resource model presented in the OCF framework provides concepts and mecha- nisms for semantic interoperability. The model is intended to capture the semantics of artifacts, devices, resources and their contexts. Sharing a semantic model is a prerequisite for two devices to interact in a meaningful way. The OCF intends to make their resource model mappable to various transport protocols, so that de- vices can interact independent of physical transport, with help from a translating intermediary.
The main concepts of the resource model are entity, resource, URI, resource type, property, representation, interface, collection and link. The mechanisms applicable on these concepts are the CRUDN operations. The concepts and mechanisms are meant to be combined in various ways to achieve the rich semantic modeling required in the diverse range of use cases within IoT.
An entity describes something that needs to be visible, accessible, and manip- ulable in the network. The entity is abstracted, or encapsulated, by a resource.
Each resource has a unique address, a URI, and properties describing aspects and capabilities of the resource. This is illustrated in Figure 2.4.
Figure 2.4: The concepts of entity, resource, URI, property, and representation in the OCF resource model.
A resource is derived from a resource type, which is the class or category of a resource, such as sensor, switch, or battery. The resource type is described in the property list of the resource, together with the device type describing the device the resource is hosted on.
A snapshot of the properties of a resource is called a representation of a re- source, also illustrated in Figure 2.4. A representation captures the state of a re- source, meaning the current values of the properties, at a particular point in time.
Representations are used for interactions with the resource, in accordance with the principles of REST. When retrieving or updating the state of a resource, represen- tations of the resource state are exchanged, in a request-response communication pattern.
If a resource has one or several links, it is called a collection. A collection is a basic building block in the OCF framework used to model and map structures and relationships among resources occurring in different application contexts. It can be used to create groups or hierarchies of resources, such as tree, mesh, or fan-out structures. The link describes the relationship between resources which is unidirectional. The parameters defining a link include target URI, context URI, relationship between target and context URIs such as "contains" or "activates", and metadata elements. An example of a collection could be the group of resources hosted on a device, as shown in Figure 2.5. The intention of the collection concept is to provide a means to refer to a set of linked resources with a single handle.
Figure 2.5: An example illustrating the concepts of collection and link in the OCF resource model.
Table 2.1 shows an example of property definitions for a resource abstracting a dimmable light bulb. Properties describe aspects and capabilities of a resource, as well as metadata related to the resource. The property is represented with a key-value pair, expressed as< P ropertyName >=< P ropertyV alue >. The OCF framework specifies resource type, resource interface, name, and resource ID as common properties, applicable for all resources.
The interface property declares the interfaces supported by the Resource. An interface provides a view of a resource, and defines the allowed requests and response interactions on that view. The OCF framework have defined standard interfaces, some of which are shown in Table 2.2.
OCF has further defined core resources enabling functional interactions. Among these, the default, platform, and device resources must be supported by all devices.
Table 2.1: An example of properties of a light resource represented with the OCF resource model (adapted from Table 30 in [2]).
Property title
Property name
Value type
Value
rule Unit Access
mode Mandatory Description
Name n string R,W no Human-friendly name
On-Off of boolean R,W yes
On/Off control 0 = Off 1 = On
Dimmer dm integer 0-100 R,W yes
Resource which can take a range
of values.
Min: 0 Max: 100
Table 2.2: A table presenting some of the standard resource interfaces defined in the OCF framework (adapted from Table 8 in [2]).
Interface Applicable
Methods Description
baseline Retrieve Update
The baseline interface defines a view into all properties of a resource including the meta properties. This interface is used to operate
on the full representation of a resource.
read-write Retrieve Update
The read-write interface exposes only those properties that may be both “read” and
“written” and provides methods to read and write the properties of a resource.
actuator
Create Retrieve
Update
The actuator interface is used to read or write the properties of an actuator resource.
batch Retrieve Update
The batch interface is used to interact with a collection of resources at the same time.
This removes the need for the client to first discover the resources it is manipulating – the server forwards the requests and aggregates the responses.
Discovery
Discovery is a function component enabling both endpoint discovery and resource based discovery. The OIC specification defines several mechanisms for device dis- covery, and there is a default discovery mechanism that should be supported by all devices. This default mechanism requires that all devices update their local core resource hosting the discoverable resources every time a new resource is instantiated on the device. Then, any device wishing to discover resources on one or more other remote devices, makes a unicast or multicast retrieve request. The remote devices receiving the request responds with their list of resources. The requester might then ask for further information about the available resource, now that it knows it exists.
Device Management
In version 1.1 of the OIC specification, only basic device management functions are defined. These are diagnostics and maintenance features, intended to be used by administrators to resolve problems occurring in the device when it is deployed and in operation.
The diagnostics and maintenance features are exposed through an optional core resource type named maintenance, which up to now only contains the two properties factory reset and reboot.
The factory reset should perform a rollback to the default state of the device by restarting it and resetting all device configurations. The reboot should perform a restart of the device but keep most of the configurations intact.
Manufacturers and developers can specify their own device management re- sources and properties to use for maintenance and diagnostics, in addition to the maintenance core resource.
Security
The aim of the OIC security specification is to protect all OIC resources, by providing a set of security mechanisms ensuring that a server enables access its hosted resources in a secure manner. Some robustness aspects of the security are dependent of the hardware platform hosting the OIC device.
The specification describes a security theory of operation in three steps. Step one is that the OIC client establishes a network connection to the OIC server. Both the server and client are OIC devices with a unique DeviceID used in the security policy. Step two is to establish an end-to-end communication channel, which should protect the exchange of messages and resources. Step three is that the server’s secure resource manager decides if the client has permission to access the requested resource.
The security specification further defines security mechanisms for access control, secure on-boarding of devices, secure bootstrap process, security provisioning, and secure device discovery.
2.3.5 Architectural Design Patterns
On a high level, the OCF architecture implements a set of metadesign patterns.
First of all, it is a middleware solution, acting as an abstraction layer, and virtu- alizing the things connected to the network. Having consistent abstractions gives the ability to connect various sensors, actuators or other objects, to various appli- cation programs, since the applications all understand the same abstractions. All in all, the virtualization of things by means of a middleware opens up the door for many-to-many interactions between things and application programs.
The abstractions are accomplished with a data model, which has to be rich and consistent in order to provide interoperability and adaptability. Only then can it enable multiple and diverse applications to operate in a consistent way with any given endpoint device.
The most characteristic feature of the OCF architecture is that it is resource ori- ented and RESTful. This entails a number of design patterns affecting the behaviour of several of the most important functional blocks. OCF has further integrated a variant of the observer pattern, enabling clients to receive notifications about state changes of observed resources. Moreover, patterns for resource discovery are identi- fied in the specification. These patterns are described in the following subsections.
Representational State Transfer Architectural Style
The REST architectural style defines a set of design principles to accomplish key fea- tures and functionality for a distributed hypermedia system, targeting high levels of interoperability, scalability, and generality. In order to retain the principles guiding REST, certain interaction constraints are applied on elements of the architecture.
REST can be explained by looking at its design principles of architectural el- ements. The main design principles of REST are the client-server communication pattern, stateless interactions, cacheable responses, uniform interfaces, and layered system. The abstract architectural elements of REST are divided into data elements, connectors, and components [25].
Data elements The first and fundamental data element is the resource, which is the concept for information abstraction in REST. A resource is any information or object, virtual or physical, that can be named. Other data elements exist to describe the nature and state of a resource, as well as define the permitted interactions with a resource.
URI is a data element used to identify the particular resource involved in an interaction between components. Next there is the representation, used to perform actions on a resource. The representation captures the current or intended state of a resource, and is transferred between components along with representation meta- data. There is also resource metadata, describing information about the resource not tied to any specific representation. The last data element is the control data, de- scribing the purpose of a message between components, such as the required action or the meaning of a response [25].
A request consists of control data, a resource identifier, and an optional repre- sentation. A response consists of control data, optional resource metadata, and an optional representation.
Connectors The connectors in REST provide generic interfaces for accessing and manipulating resources. The purpose of connectors is to simplify the communication with components by separating the concerns and hiding the details of the underlying implementation of resources and communication mechanisms.
The primary connector types are the client and server. A client initiates com- munication by making a request, a server listens for connections and responds to requests. A component may include both client and server connectors managing its network communication.
Other connectors are cache, resolver and tunnel. The cache can be placed in the client or server interface to save cacheable responses to be reused in later interactions.
