I would also like to thank my friends and colleagues in the International Peer Mentor team at the University of Adelaide. Despite the mentioned potential and benefits of reuse-oriented IoTSE engineering, a majority of IoTSE instances in the literature have been designed and developed from scratch.
Research Objectives
The reuse-centric IoTSE technique would enable more effective and efficient IoTSE instances by allowing them to leverage state-of-the-art implementations for their internal operations. This problem may be due to the lack of a reference architecture and software infrastructure to guide and support the construction of IoTSE instances.
Contributions
Publications Related to this Thesis
Internet of Things Search Engine: Concepts, Classification and Open Issues.” Communications of ACM (Chapter 2). Under review)Tran, Nguyen Khoi, M. A Reference Architecture for Internet of Things Search Engines” ACM Transactions on Software Engineering and Methodology (TOSEM).(Chapter 3). To be published) Tran, Nguyen Khoi, M.
Thesis Structure
Internet of Things search engines (IoTSE) connect users and applications to IoT resources. An overview of the growth and state of research and industry efforts surrounding IoTSE.
Background
The Web of Things
In Section 2.4, we present the analytical framework for our study, which is built on our proposed models. We apply this framework to academic and industrial efforts and present the results in sections 2.5 and 2.6, respectively.
Discovery and Search in the IoT
In WoT, applications communicate with physical objects using the familiar HTTP protocol and RESTful API. First, the Internet of Things contains a large amount of short, structured text and non-textual content (e.g., sensor streams, functionality), while web search engines are optimized for long, unstructured text.
A Model for Internet of Things Search Engines
Meta-path: The Signature of an IoTSE
The first part [QueryResType[Feature] +..] describes the types of resources used by a search engine to evaluate queries. For clarity, a meta-path also represents resource properties that include query evaluation.
An Modular Decomposition of IoTSE
For example, the MAX search engine [35] discovers relevant objects in its vicinity during the query resolution process by issuing the query. The Query Processor module transforms raw user queries into the form that can be processed by the system.
Analytical Framework of the Survey
We use the number of publications and citations in the field (ie, references among over 200 IoTSE works) each year to assess the growth of the field. For the detailed analysis, we map a subset of works against the dimensions that we built in the second part of the framework.
Research Prototypes
Overview of Major Research Prototypes
It can search the newly captured image or the set of images stored in the camera sensor node. This collection is virtual, as it is not explicitly stored in the search engine's memory.
Publication and Citation Analysis
People use structured queries in the form of (Location,{Keywords}) to interact with the system, while smart devices use a CoAP RESTful API. The lack of citation in the field is a possible indicator that most works around IoTSE are not noticed by their peers.
IoTSE Form and Implementation Analysis
Discovery Schema Mobility Support Collection Type Collection Type Index TypeQ.I Storage Sort Search Scalability SchemaQuery Result ModelQ.D Sort Search Suitability Scalability User Type Interface ModalQuery InterfaceResultsSecuritySecurityPrivacyPrivacy. (Rnk)--HWTBxL-OAC,LAC- GSN (Aberer, et. al. 07)ATLDR---AHIDStrExt--M---CrptOAC- SenseWeb (Kansal, et al. Discovery Scheme Mobility Collection Support Type of collection Type of indexQ.I Sorting Scalability of storage Search schema SearchQuery Model ResultQAvailabilityReference ceResult InterfaceSecurityPrivacyTrust CASSARAM (Penera, et. al.
Industrial Works and Standards
Overview of Industrial Works and Standards
Discovery Scheme Mobility Support Index Type Q.I Ranking Storage Scalability Q.D Ranking Adaptivbility Search Scalability Security Privacy Trust. On query model dimensions, logical conditions are the most common form of query, while source list is the most common result model. a) Discovery scheme (b) Collection type (c) Search scheme.
Evaluation
The search capability provided is basic, such as filtering objects by ID and their metadata. These standards revolve around the "Discovery Service", which finds Information Systems on a network (eg, the Internet) that hold information corresponding to a particular object identifier.
Discussions
- Crawling IoT
- Supporting Location-based Search
- Supporting the Dynamic Nature of IoT
- Supporting the Diversity
- Supporting Scalability
- Security, Privacy and Trust
An alternative solution is to distribute IoTSE closer to the edge of IoT and connect them in a federation to provide global coverage. Therefore, a key concern of IoT search engine is to protect the privacy of searchers, information owners and found people.
Related Work
Summary
By presenting a blueprint for engineering IoTSE instances, this chapter addresses the second research objective of this task: to propose a reference architecture that captures IoTSE commonalities. Finally, the building blocks and patterns defined by the reference architecture lay the foundation for enabling reuse-focused IoTSE engineering.
Methods for Developing the IoTSE Reference Architecture
Phase 1: Study Selection
Unlike the SLR method, we also performed the “snowball search” where we retrieved references from the potential primary studies and created a graph of citations between them. Excludes any information retrieval study not involving IoT or WoT unless referenced by at least two included primary studies.
Phase 2: Information Extraction
These works have been selected in a way that balances highly cited work with new work to capture both the "norm" and the evolution of IoTSE research.
Phase 3: Architecture Design
The remaining activities at the end of the process became the building blocks of IoTSE. For the identification of IoTSE composition patterns, we maintained a sequence catalog of IoTSE building blocks and updated it with newly identified IoTSE building blocks by the end of each iteration.
Data Extraction Results
Interaction Patterns
The // sign indicates that two series of activities before and after it are executed in parallel.
Deployment Patterns
A Reference Architecture for IoTSE
- Meta-model
- Layers and Architectural Building Blocks
- Composition Patterns
- Deployment Patterns
It receives identifiers or addresses and returns IoT content as outputs.Content Collector building block encapsulates this capability. Two patterns in this group differ in the timing between index generation for different types of IoT content.
A Framework for IoTSE Instantiation
The second step involves constructing composition patterns for the IoTSE instance based on subpatterns defined in the reference architecture. Finally, the infrastructure built in the second phase is used to realize these patterns and generate complete IoTSE instances.
Evaluation
Methods
We selected a sample of two prototypes from more than 200 existing works based on the following criteria: (i) they should be representative, meaning that their approaches and architectures should appear in multiple studies; and (ii) they must use a complex composition and implementation architecture.
Results
Finally, the reference architecture can model the implementation structure of the prototype with its implementation patterns. In terms of discovery, IoT-SVK is mapped to patternSI as it only includes storage and indexing activity.
Threats to the Validity
The second threat to the internal validity of our assessment is the correctness of our mapping from Dyser and IoT-SVK to the reference architecture. Threats to external validity A threat to the generalizability of our assessment is the size and representativeness of selected IoTSE prototypes for testing the reference architecture.
Related Works
It is capable of searching for ontologies, of a Semantic Web document, and of answering questions about the structure of a Semantic Web search engine. 88] present Google's architecture that supports large-scale collection and storage of HTML documents, extracting links between documents, stores various information about documents, link structure and anchor texts, and resolves queries on these documents in a very scalable way.
Summary
Component developers need a software infrastructure that helps them transform their algorithms and mechanisms into reusable, composable IoTSE components. Furthermore, this core can also provide templates for developing IoTSE components that are compatible with the reference architecture.
Background
Web Sensor Retrieval System
For example, a WSR instance that queries temperature-humidity sensors (e.g., DHT22) for seasonal features of their observations may be composed of modules that detect, analyze, index DHT22 sensors, and resolve seasonal feature queries in time series. Extending the WSR instance to support other types of sensors and queries can be done by modifying its modules.
Discovery
While the challenge of diversity can be addressed by equipping WSR instances with every mechanism and algorithm available to work with every sensor and query, this solution is not suitable for WSR instances deployed in resource-constrained scenarios (e.g. by by assembling a wide selection of detection components and looking for different types of sensors, and then selectively composing them into WSR instances, these systems can be adapted to different usage scenarios without over-engineering.
Search
However, larger sensor infrastructure and more complex queries, such as finding "power consumption sensors on the fourth floor of the campus building that detected anomalies in the last 24 hours", require more sophisticated query mechanisms. In our project, IoTSE is designed based on a subset of the Sensor Thing API model.
Anatomy of WSR
Reusable Processing Chain
Each member encapsulates an independent and reusable treatment such as denoising, accumulation of data and scoring. By organizing complex processing into independent modules, the reusable processing chain model facilitates the systematic reuse of processing mechanisms and algorithms across IoTSE instances.
Adaptability of the Modular Architecture
Kernel-based Approach to Developing WSR
Abstract Modules
They are specified by the Lv.2 kernel in the bootstrapping process. Module parameters and sub-modules are specified by WSR instance developers in configuration scripts. For example, in AbsRunnableModule that represents a module running on a separate thread, the loop()concrete method repeatedly calls the abstractproc() method after each adjustment.
Bootstrapping Process
Evaluation
We deploy one instance of WSP on the RPi3 to mimic the building sensor platform. The other is deployed on a workstation to mimic the city's sensor platform.
Discussion
Related Works
Early research prototypes, including MAX [35], Microsearch [46], and Snoogle [38], focus on searching for sensor nodes based on their embedded textual content. As WoT and web sensors emerge, more and more works focus on querying sensors based on their observations at the time of the query.
Summary
The completed case study has shown that the kernel-based approach can reduce the amount of new code when developing a multimodal IoTSE instance to only 30%. In this chapter, we propose a platform-based approach to IoTSE engineering that extends the kernel-based approach to support new classes of IoTSE and prepare features that may appear in future reuse-centric IoTSE engineering, such as automatic composition and insertion.
Introduction
The mentioned opportunities for improvement motivated us to extend the kernel-based approach to the platform-based approach to IoTSE engineering. We would like to emphasize that the platform-based approach reported in this chapter neither invalidates nor makes the kernel-based approach obsolete.
Motivating Scenario
To assess the feasibility of re-use-focused IoTSE engineering using a platform-based approach, we conducted 3 case studies involving the engineering of 16 IoTSE instances of increasing complexity. Let's look at two scenarios (Figure 5.1) that require two IoTSE instances.
Requirements of the Software Infrastructure
Determining the Functional Requirements of the ISEP Infrastructure 126
From each of the IoTSE prototypes, we extracted the topology and physical location of its computing nodes. Two notable features of the IoTSE architecture that emerged from the extracted data are the distribution of an IoTSE instance across computing nodes and the utilization of.
A Platform for Engineering and Operating IoTSE
Components of the ISEP
In the context of engineering IoTSE components as containerized web services, the frontend engine is a web server. Thetools for developersgroup provides software tools for packaging and publishing IoTSE components to the various repositories that form its group.
Feasibility of the Platform-based Approach in the Reuse-centric IoTSE
- Method
- Case Study 1
- Case Study 2
- Case Study 3
This class is almost identical, functionally, to the one in the first case study. Patterns specified in the first case study were reused to generate four IoTSE instances from six components.
Discussion
Threats to validity
The identified requirements are based on the motivating scenario, which leverages a specific architectural vision for IoTSE. To address this threat, we emphasize that the platform, as described in section 5.4, is independent of the chosen architectural vision for IoTSE.
Related Works
One could argue that the IoTSE prototypes analyzed do not represent IoTSE as a whole. Since all the analysis and functional decomposition of IoTSE instances in three case studies used the eight specific types of services (Table 5.3), it can be argued that the proposed solution is only applicable to this architecture.
Conclusion
Providing a holistic insight in the current state of IoTSE
The first purpose of the thesis was to provide a holistic insight into the current state of IoTSE research and development. When this study was completed, its coverage in terms of the number and diversity of IoTSE works was unprecedented.
Proposing an IoTSE Reference Architecture
These works are representative and represent the extremes in terms of architectural complexity in the IoTSE literature. In both cases, the workflow and deployment structure of the prototype were fully captured by the components and patterns proposed in the reference architecture.
Proposing a Software Infrastructure to support Reuse-centric IoTSE
Finally, we introduced a framework to guide the instantiation of IoTSE instances from the reference architecture. The case studies conducted in the following research on the software infrastructure, which involve the construction of IoTSE instances based on the reference architecture, further validated its suitability and applicability.
Limitations
Limited Support for Decentralized IoTSE
A decentralized IoTSE instance consists of functionally equivalent peer nodes, each of which maintains a subset of the IoT content discovered by the IoTSE instance. Our focus on capturing the commonalities of IoTSE in the reference architecture led to this limitation, as decentralized IoTSE has yet to be the norm in the IoTSE literature.
Limited Support for Security, Privacy, and Trust
They tend to resolve incoming queries locally before propagating them to other nodes in the instance. For example, it does not model the topology of the overlay network, the routing algorithm, or the consensus mechanism used by a decentralized IoTSE instance.
Extending Results
IoT Gateway Engineering
We can then apply the kernel-based approach to gateway engineering similarly to IoTSE engineering. The kernel-based approach was particularly well-suited, as IoT gateways do not require complex workflows or distributed deployment like IoTSE instances.
Investigating Impacts of IoTSE Architecture
We used the outlined approach to design the IoT transition that emerged in our case studies.
Future Work
Developing Formal and Semantic Descriptions
Accumulating Architectural Knowledge
Automating IoTSE Composition and Deployment
Low-Cost, High-Accuracy Prediction Model for Content-Based Sensor Research in the Internet of Things. Internet of Things Research on the Web: Where it is and what it looks like.
Distribution of Meta-paths and Operating Scopes
Support of Prototypes on key Dimensions
Statistics of key Dimensions
Evaluation of IoT search engine industrial efforts (a) and standards (b)
Modular construction of Web of Things Search Engines
Comparison between Federated and Centralized IoTSE
Meta-model describing the proposed reference architecture
Layers and architectural building blocks making the reference architecture
A taxonomy of IoTSE composition patterns
Detail of IoTSE composition patterns. Abbreviations used: SD - source
A taxonomy of IoTSE deployment patterns
Four phases of the instantiation framework
Mapping of IoT-SVK components and deployment structure to the reference
Mapping of IoT-SVK workflows into interaction patterns defined in the
Mapping of Dyser components and deployment structure to the reference
