5.5 Feasibility of the Platform-based Approach in the Reuse-centric IoTSE
5.5.2 Case Study 1
5.5 Feasibility of the Platform-based Approach in the Reuse-centric IoTSE Engineering137 The runtime environment of the platform consists of Docker daemons that resides on computing nodes hosting an IoTSE instance. These daemons are connected to each other and to the host that offers operator’s tools.
Test Bed
All IoTSE prototypes and experiments were hosted by a Linux-based workstation with a quad-core Xeon E3 CPU and 8GB of RAM. Up to three virtual machines would be hosted on the workstation, depending on the deployment pattern of an IoTSE prototype in an experiment.
IntelLab dataset2was utilised to demonstrate the functionality and performance of IoTSE prototypes. This dataset consists of data from 54 sensors deployed in the Intel Berkeley Research lab between February 28th and April 5th, 2004. These sensors report timestamped topology information, along with humidity, temperature, light and voltage values once every 31 seconds.
In order to expose these data streams on the Web as IoT-enabled sensors, a NodeJD-based sensor gateway was developed. This gateway transforms metadata and sensing data of sensors into JSON documents and serves them as Web resources according to the SensorThings API standard3developed by The Open Geospatial Consortium (OGC).
sensors, retrieving sensor metadata, storing and indexing sensor metadata, and resolving queries for sensors with the collected data and generated index.
Component services to be implemented were derived by matching the identified function- alities with the types of component services codified in the reference implementation of the platform (Table 5.3).Six component serviceswere identified and implemented:
Source Detector is responsible for detecting IoT gateways. It belongs to the Detector component type. For detecting sources of IoT data, the IoTSE literature reports various approaches such as utilising multicast DNS (mDNS), multicast CoAP, Simple Service Dis- covery Protocol (SSDP) and developing specialised crawlers for the Internet of Things (e.g., [62]). As our experiment involves only one IoT gateway and our focus is on the integration of IoTSE components, not developing state-of-the-arts ones, we opted to provide the address of IoT gateway to the source detector instead of implementing detection mechanisms.
Sensor Detector is responsible for detecting endpoints of IoT-enabled sensors hosted by the gateway. It belongs to the Detector component type. This task is complicated as the interface to access sensors varies significantly between IoT gateways. We developed sensor detection based on SensorThings API standard, which specifies templates for endpoints of IoT-enabled sensors. As our IoT gateway was also compliant to the SensorThings API, sensor detection was possible.
Metadata Collectoris responsible for collecting metadata of detected sensors. It belongs to the Collector component type. Data extraction and parsing were implemented based on the data template defined in the SensorThings API standard.
Metadata Searcher is responsible for storing, indexing, and resolving queries on sensor metadata. This component service combines the capability and interface of Storage, Indexer, and Searcher component types. This combination was motivated by the large and frequent flow of data between them. Implementation of this component was based on the capabilities offered by MongoDB – a NoSQL database.
5.5 Feasibility of the Platform-based Approach in the Reuse-centric IoTSE Engineering139 An Aggregatorand a Facadecomponent service were implemented to complete this IoTSE instance, according to the architectural vision codified in the platform. The aggregator was implemented to return the intersection of multiple lists of search results based on sensor ID. The facade is responsible for offering a single point of access to the IoTSE instance. It was instantiated from the platform without alteration.
Architectural patterns
Two composition and two deployment patterns were utilised to generate four IoTSE instances from six component services.
Two deployment patterns used werecentralisedanddistributed, in which detector and collector components were deployed on one virtual machine while remaining components were deployed on a different virtual machine.
Two composition patterns used wereParallel Discovery (PD)andInterlaced Discovery (ID). In PD, the detection and collection of IoT content are carried out independently from the query assessment activities. In ID, the detection and collection of IoT content is invoked only on reception of a query. This pattern emerges from IoTSE prototypes.
Results
Four IoTSE instances were subjected to a query for IoT-enabled sensors that measure
“apparent temperature” in “degree Celsius”. All instances achieved perfect precision and recall because a database was utilised for storing and resolving queries on sensor metadata.
For conciseness, query and search result samples of each instance are omitted in favour of the excerpts from multi-modal IoTSE instances in Case Study 3 (Figure 5.3).
The response time IoTSE instances utilising the Interlaced Discovery pattern was around 6 seconds on average, while instances with the Parallel Discovery pattern responded after 3 seconds on average (meta_ID_Candmeta_PD_Cin Figure 5.4). The overhead on both
patterns was around 1 second (Figure 5.5a). Due to having much shorter response time, the pattern PD was subjected to higher percentage of overhead, which reaches 35% on average (Figure 5.5b).