• The work of [210] is used for the indoor scenario. There is no mention on the mecha-nism to create and configure custom virtual sensors and actuators.
From all points above, there are no comprehensive solution proposing a robust virtual sensor framework along with a friendly web-based interface. In addition, leveraging virtual sensors to present historical data is not supported. Our framework is designed and implemented to mitigate these limitations.
5.3 Virtual Sensor Framework
In this section, we present the definition and taxonomy of the virtual sensor as well as our virtual sensor framework architecture. Such framework is designed based on layered architecture and operates over clustering and asynchronous model to maximize scalability and performance. At the end of the section, we describe the work-flow of the proposed framework in specific deployment scenarios to emphasize its benefit.
5.3.1 Virtual Sensor Definition
We define the virtual sensors as virtual objects, which have operators to perform specific functionalities. In our proposal, we support three operator types including rules, formulas, and functions. We propose a novel taxonomy of the virtual sensor based on its operator.
For instance, a virtual sensor is defined as an “Accumulator” type if its operator is an accumulation function. The list of supported virtual sensor types is described below:
• Singular: This sensor type is a one-to-one mapping between the physical sensor and its reflected interface on cloud. Through this virtual interface, the end-user obtain sensed data from physical sensors.
• Accumulator: A virtual sensor performs accumulation functions on its sensing data within a particular duration. For example, a physical sensor measuring rainfall uses the counter value to identify rainwater volume. An accumulator VS is useful to present the rainwater volume within 24 hours by accumulating on these counter values.
• Selector: A virtual sensor represents sensing data from one or many physical sen-sors based on defined criteria. For instance, a selector virtual sensor represents all temperature data that is higher than 10 degrees.
• Aggregator: A virtual sensor performs basic statistics (such as averaging, maximum, and minimum) on collected data from different physical sensors. For example, in the case of humidity sensors deployed in various regions, an aggregator sensor is used to calculate the average humility of a specific area.
• Qualifier: The same with the singular type but this virtual sensor type only is activated by a qualifier function, which is an IF ELSE statement. For example, one qualifier virtual sensor monitoring temperature can generate an alert when sensing value higher a defined threshold.
• Context-qualifier: The same with qualifier type but the qualifier function performs on a bundle of sensors.
• Predictor: This virtual sensor predicts next sensing values based on analyzing his-torical data. Such virtual sensor is necessary in case of occurring error on the physical sensors.
• Compute: A virtual sensor has a complex function analyzing the sensing data from a set of the sensors. For example, a compute virtual sensor offers the car statuses based on observed data (such as engine temperature, oil level, and gas level) from car’s sensors.
On the other hand, we present a novel component, namely “logical data flow”, which repre-sents a chain of virtual sensors to perform a specific task. For example, a logical data flow is used to identify the remains of liquid in a tank from ultrasonic sensor data. This LDF is a chain of one singular virtual sensor, one selector virtual sensor, and one aggregator virtual sensor.
5.3.2 Architecture Overview
Figure 5.1 – The framework architecture overview.
Our goal is to produce the high-level information from sensing data. To achieve this goal, the framework simplifies creating and configuring the logical data flow by offering an inter-active virtual sensor editor. Fig. 5.1 depicts the framework architecture composing of three horizontal layers described below.
• Connection Layer: This layer handles the connections between sVSF and Sen-sor Data Service Platform(SDSP) which aggregates and pre-processes collected data from physical sensors. There are three components: (i)Sensor Data Connector: This component is used to interact with SDSP through RESTful web services and MQTT.
(ii)Sensor Configuration Synchronization: This component synchronizes sensor con-figuration between sVSF and SDSP. In addition, the concon-figuration of a singular VS will be applied to corresponding physical sensor managed by SDSP through calling a RESTful web service. (iii)Sensor Tracking: This component is used to track the new sensors recently registered to SDSP. These sensor profiles are transferred and stored at sVSF.
5.3. Virtual Sensor Framework 47
• Processing Layer: The main components of this layer is databases and a primary engine to execute the logical data flow. There are two databases: (i) Sensor Data Storage database permanently stores sensor information and LDF. (ii) Temporary Data Storage database stores temporary outcomes of virtual sensor as well as inter-mediate results of LDF. Such data will be removed after a short duration configured by administrators. Apart from these components, the processing layer has a “Sensor Composition” (CP) component to retain a record of configuration and relationship among virtual sensors at the presentation layer. When a new virtual sensor is created by dragging and dropping onto VSE, such changes are caught and stored by CP. In addition, the CP ensures the logical data flows executed following the asynchronous model. The final component is a user-defined function library storing the custom functions declared by end-users. These functions are executed directly from CP.
• Presentation layer: This layer is used to render an interactive HTML5 web inter-face, namelyvirtual sensor editor. The editor supports the end-user to create a logical data flow. The virtual sensors are visualized as linkable boxes that can be configured either functionality or appearance via a setting panel. These boxes can be linked together to create a logical data flow. All such operations are handled by “Sensor Composition” component in the under layer. Moreover, the presentation layer has a
“Data-flow Profile Selector” component used to select and reuse the existing virtual sensor templates and LDFs.
• Administration layer: This layer authorizes and supervises the user access right on VSs and LDFs. Each user type is only able to perform specific actions based on its roles. For instance, a standard user cannot delete a LDF. The administration layer is also used to manage general settings of the framework, such as the time life of temporary data, sensor configuration synchronization interval.
5.3.3 Virtual Sensor Framework Workflow
Figure 5.2 – The framework operation diagram.
The overall blueprint of our sVSF workflow is shown in Fig. 5.2. Initially, physical sen-sors register their resource descriptions underCoRE Link Format [211] with SDSP. Once successfully registering, all sensing data from registered sensors will be forwarded to sVSF.
These sensors and their resources are discovered through simple search queries. For in-stance, a query searching all temperature sensors is “GET /rd-lookup/ep?rt=temperature”.
In sVSF, the incoming data is handled by the connection layer. Then, it is conveyed to the Sensor Composition element which processes the VS operators and relationships in the logical data flow. This component also takes responsibility to convert VS operators to the proper mathematical operations and ensures it is executed in the correct order in the processing engine. The conversions of VS operators into mathematical operations pass through two phases: In the first phase, the logical data flow and sensor information are loaded into CP. In the second phase, the particular variables of the operators are extracted and calculated by executing the corresponding functions inFunction Lib Component (FL).
These variables represent particular operations. For example, as shown in Fig. 5.4, $de-vice.tank_level_change.data[24] represents all sensing data of “tank_level_change” sensor within 24 hours. After calculating, the values of special variables are added into the virtual sensor operators before storing in the temporary data storage database to reuse in another stages. The lifetime of this temporary data is set up by administrators. In case the virtual sensor has the input from another virtual sensors. This input value is also considered as a special variable and directly access via the sensor name. As example shown in Fig. 5.4, a sensor, namely “tank_volume”, use the output value of “tank_level” sensor via declaring a special variable named “tank_level.” Furthermore, to maximize performance, Sensor Com-position organizes a working schedule based on the asynchronous model. The non-relational virtual sensors, unlinked together, are arranged into the same thread and executed in par-allel. For example, in Fig. 5.3, all green virtual sensors are performed in parpar-allel. In the next step, the virtual sensor operator is executed in a processing engine developed by a JavaScript library, namely MathJS . Finally, the output of processing engine is stored in the database before responding to SDSP.