This work surveys Internet of Things (IoT) experimental research published since 2015. We summarize the IoT state of the art during the last 2 years and extract important data that we apply to enhance the analysis of IoT solutions. The IoT scenario presents a promising universe to data analysis. This raises a number of questions: which are its most popular applications? What is the definition of scale in an IoT application? What sensors are more often used and for what IoT applications? How can a researcher compare IoT scenarios? To investigate these concerns, this survey analyzes 2 years’ worth of contributions made in three main scientific publishers. We focus on IoT experiments that were actually implemented using real equipment within one or more scenarios. Our first contribution is the classification of those IoT scenarios into seven main aspects. Each analyzed research study presents a specific configuration of a scenario’s variables and sensors. Our second main contribution takes place after the scenario mapping phase. We identify as many as 19 common categories of data types in use. The interrelation among the scenarios and the data types from sensors should assist data researchers in understanding current IoT dynamics.
Notes
Cleber M. de Morais and Judith Kelner contributed equally to this work.
Abbreviations
ACM
Association for Computing Machinery
API
Application programming interface
ECG
Electrocardiogram
EEG
Electroencephalogram
GPS
Global positioning system
IEEE
Institute of Electrical and Electronics Engineers
IoT
Internet of things
NFC
Near field communication
ORP
Oxidation reduction potential
pH
Potential of hydrogen RFID: Radio frequency identification
SAAM
Scenario-based architecture analysis
Introduction - IoT as a paradigm
The Internet of Things (IoT) is a computationally supported information system paradigm [1, 2] that embraces a variety of applications. IoT services differ from other IT-related techniques found in industrial or home office context due to their ubiquitous and embedded characteristics that permeate our daily lives [3]. While the main IoT architecture(s) is still under definition, their underlying paradigm offers the means to gather one or more “things” (sensors, interactive devices, or even complex ones) using well-defined communication interfaces. These can then share data and communicate with the outside world through some specially designed network gateways [4, 5]. The final result is similar to service-oriented architectures that can be subject to service orchestration (e.g., through their APIs). IoT events and information are processed and presented as application output to a human’s interaction or used for autonomic decision. Furthermore, the IoT paradigm allows applications to interact with machines, things, and/or humans through actuators to enforce new control.
A case in point is a farm equipped with soil humidity and temperature sensors. The farmer’s information dashboard may present sensors data in a geographical and analytic way. Knowing the humidity levels, a farmer may decide whether or not to irrigate the soil. This also depends on the type of crops planted. Then, the irrigation actuators can be activated to increase field humidity. The IoT paradigm creates new opportunities for specialized small devices (sensors and actuators) while it also introduces new challenges for the storage and retrieval of large amounts of data and its meaningful visualization [6].
Advertisement
Such hyper-connected information sources often provide a large-scale data offering. This is classified as a Big Data scale problem for storage, retrieval, and analysis [7]. The data analysis aspect is challenged by an intense data input, constant mutation, and complex scenario representation. Other similar large data applications include those in a metropolitan scale [8] such as smart city services, domestic appliances in the context of the smart home [9], and industrial applications [10].
In those applications, the data intensity constraints may vary from within minutes to real time, for each sensor. Accordingly, each scenario demands a different data strategy to deal with the context of each data. The scenario-based architecture analysis (SAAM) is considered quite mature in the software engineering field [11]. Scenarios have been used during system design as a method for comparing design alternatives for development [12]. Some works classify the IoT objects (as in [13, 14]), but this strategy has not been applied to IoT scenarios so far.
The present work aims to help in answering some research questions that may occur to data analysis researchers. We provide the reader with details of the most common emerging IoT scenarios currently found. We explain the way data structures and demand can change from one scenario to the next. A classification of existing sensors ranked in terms of popularity and its application is presented. More importantly, we qualify the different attributes according to usage contexts and provide guidelines for their data analysis [15]. Finally, we provide a technique that binds sensors’ qualification with the scenario’s description in an analytic way.
First, the procedures that were used is this survey are described in the “Methodology” section. After that, the “Analysis” section will present the classifications and categories used by this work. Then, the results are presented, showing the major contributions of this work. At last, the conclusions from this research, some future works, threats to validity, and references are described. To help the keen reader further in exploiting our results, we also provide in the Appendix Appendix 1: List of surveyed papers and classifications section the main raw data of analysis and the identified structures.
Advertisement
Methodology
This work falls into the category of analytic bibliographical research. Three main publishers (namely, ACM, IEEE, and Springer) were considered as part of the main corpus of analysis. The selected time frame is from 2015 to 2016, to show the newest applications and sensors in a closed sample. The initial search query was “Internet of Things” and “Experiment.” The objective was to sample all papers that actually implement a concrete IoT solution, with real sensors in a context or domain. The total number of examined papers reached a staggering 1087. After this first selection, the inclusion and exclusion criteria (described below) were applied to filter out some of the works.
Inclusion criteria
The inclusion criterion was that any article must have as its focus IoT technology while also presenting an experimental setup or testbed running over real hardware. In addition, the publishing date must fall between the years 2015 and 2016, inclusive.
Exclusion criteria
The papers that did not deploy real sensor(s) in a given application domain were classified as out of the scope of this analysis and removed from our study. We also excluded papers that enhanced one aspect of IoT performance, but lacked an implementation into the considered system. This was the case for example of research describing enhancements made to sensor network communications protocols. A similar strong exclusion criterion regarded works that exclusively used simulation and simulated sensor operation. Note that IoT solutions that process data from a dataset or trace, as opposed to data being gathered by sensors, were also excluded from this sample. Finally, the sample did not include studies published in books and book chapters, concentrating only on scientific articles.
Resulting sample
The final result consisted of 48 articles from the three data sources that satisfied our selection criteria (see Table 1). Although the resulting sample seems reduced, it represents the most relevant papers that have real implementation. This is a tricky point, because the majority of the IoT systems are too complex to be implemented, even in small scale. So, each deployed application should be valued, to further research studies. The actual state of an IoT application is crucial to better understand the complexity of data analysis, visualization, and sensor utilization.
Table 1
Sample distribution by publisher and year
2015
2016
Publisher’s total
ACM
5
4
9
IEEE
4
14
18
Springer
7
14
21
Year’s total
16
32
48
Sample’s analysis
The analysis section is split into three parts: scenario, sensors, and application analysis. The first part classifies and qualifies the context of use of IoT solutions. The objective is to understand how each IoT scenario is placed and its idiosyncrasies. Then, the second part of the analysis focuses on the sensors themselves. The main concern is the sensor classification and its application in each case. The last part of the analysis offers the classification of the use of sensors, within a characterized scenario. As an example, a temperature sensor can be used for an agricultural or an e-health application.
Analysis
Scenarios’ variables
A main aspect of the IoT scene is how the context of use and scale can change the data analysis. An IoT application can vary in many aspects. As an example, a smart city and a smart home are both categorized as IoT, but the smart city’s challenges are much more complex and demanding.
The scenario configuration is critical to understand and develop a better data analysis solution. The IEEE’s IoT working group built a platform in an attempt to catalog scenarios1. This scenario catalog is useful, but it does not allow the comparison and inter-relationship among the registered scenarios. Beyond the description of a use case, the scenario analysis can be enhanced if its classification could be analytic. Furthermore, this systematization might also be used by other applications, as in ontology. In this section, the scenario’s characteristics from an IoT implementation are described in an analytic way, to perform comparison and identify possible relations among the scenarios.
Analyzed variables
The IoT scenarios present a complex configuration. The “thing” concept itself is debatable in many works. The variation of what is defined as IoT is huge. An IoT domain may span a single room or an entire city. Also, the quantities of sensors and data upload rates vary in every scenario. Those differences raise the need for identifying and classifying each IoT scenario. We need to identify the similarities and differences among the considered scenarios. For example, one should understand which aspects of a smart city IoT system could show similarity to those from a smart industry. Scenario classification is one of the major contributions of this work and it should advance this topic.
This paper classifies the scenarios using seven variables (see Table 2 for description). Those variables represent the ability to relate to space (mobility, density, and area), people (human interface), and sensors (heterogeneity, intensity, and actuability2).
Table 2
Scenarios’ variable description and quantifier
Variable
Description
Quantifier
Density (DEN)
Density represents the quantity of sensors placed in one area.
When the area has a single sensor, it is classified as “0.” If the area has up to five sensors, it is defined as “1”; over 5 and under 15 sensors, a “2” is allocated, and the density is “3” when there are more than 15 sensors in an area.
Mobility (MOB)
This is the thing’s ability to change location in an area.
“0” is attributed for a static sensor. If the sensor can change its location in a predefined route, it is classified as “1.” When the sensor has the ability to move across areas, it is given a “2.” And in the case of large changes, as in a city scale, it is represented as “3.”
Intensity (INT)
This reflects the sensor’s data refresh rate. A higher refresh rate makes the data register more critical.
Data refresh rate over 5 min are classified as,“0”; between 1 and 5 min as “1”; each minute as “2,” and real-time “3.”
Heterogeneity (HET)
This denotes for the variety of data types and sensors in the context.
Just one sensor with one data type is represented by “0.” A sensor with various data type is classified as “1”; various sensors with one data type are labeled “2,” and various sensors with various data type are classified as “3.”
Area (A)
This is the geographical displacement of the things.
A single room is represented as “0”; a single store building as “1”; more than one store building as “2”; “3” represents a smart city.
Human interface (HI)
This variable registers the degree of interaction of the thing with a human being.
Ranges from “ 0—not related” when the device is independent of human input, “1—weakly related” when the device/thing is used or held by a human, “2—moderately related” when the sensor is a wearable device, or “3—totally related” when it is a direct input interface (neurotransmitter) or implanted chip.
Actuability (ACT)
This represents the capability of a thing in the system to act.
Ranges from “sensor only” (0), “self-acting/self-reconfiguring” (1), “acts in the environment” (2) to “acts on an external thing or human being” (3).
The first group of variables is related to the space dimension of the IoT scenario. One common concern is the spatial distance between nodes and gateways. This aspect is represented by the area variable, which ranges from a single room to a whole city. Along with the spatial distance, the number of items per area, classified as density, is a crucial measure to understand a scenario. A wide area might have only a few sensors in one experiment, but some other experiment might implement a large number of sensors within a small area, as is the case in an industrial application, for example. The last variable related to space is mobility. Mobility is the ability to move in or in-between areas. We observe that these three variables can change according to the application and even within the same application type.
Heterogeneity and intensity are variables directly related to sensors themselves and their displacement. Intensity is the amount of data provided by a sensor in a determined time frame. Higher intensity denotes a more intensive service and demands a better network, storage, and processing infrastructure. Heterogeneity is related to the variety of sensors in the area. Many different sensors demand complex correlations to their values and different strategies to understand data.
The last variables are related to elements outside the IoT sensing and processing domain. The human interface represents the human interaction as data source to the system sensing part. Higher human interface denotes more system dependency on human data to produce information. Actuability is the capability of an IoT system to interact with actuators and interfere with other objects and people. This can happen through a light switch, turning on or off a light, or even an information display to a person (not system user) showing some system status information (e.g., an accident LED display in a smart road). In addition, actuability refers to the capability of the sensor to reconfigure itself, change proprieties, and restart.
Those variables will be invaluable to classify each scenario. In the section describing our results, this classification will be applied to understand and represent each scenario from the sample. In the next section, the sensors’ characteristics will be presented.
Sensors’ analysis
Sensor data is classified according to its application. The initial taxonomy for classification was presented by Harbor Research and Postscapes’ analysis3. Some categories were merged into bigger ones to better understand the scenarios’ characteristics. As an example, the humidity and temperature sensors were joined under the “ambient” sensor type, as both represent a variable that measures something in the environment. The sensors were divided into 14 categories presented below (see Table 3 for a synthesis).
Table 3
Sensors’ classification
Category
Description
Ambient
This refers to sensors that gather data from the environment or the space around them.
Motion
This is used to perceive motion of people or things in a context (as in accelerometers and gyroscopes).
Electric
This category holds the sensors that are applied to electricity grids.
Biosensor
The biosensors are worn by humans or animals. They return vital signs and/or biological information about one subject.
Identification
This represents a semantic or identity of another thing to the IoT system. The most common items in this classification are RFID and NFC tags and their readers.
Position
This is related to identifying an object’s position in a global scale (as with GPS) or in a local scale (as in small beacon position).
Presence
This captures the presence of a person, an animal, or object in a space and registers it in the system. The most common solution is the PIR sensor.
Machine vision
This family of sensors captures images that will be processed by a computer to produce information.
Interaction
These types of sensors are devices that are human-activated to trigger an event, such as a button or a lever.
Acoustic
Such sensors are activated by soundwaves, producing data from the ambient sound change.
Force/load
The force/load sensors are activated by external forces, capturing the deformation or the intensity of those forces to the system.
Hydraulic
These are applied in the water system to measure and control the flow.
Chemical
Chemical sensors are capable of detecting chemical substance(s) in the air or water.
Object information
This specific category includes sensors with similar functions to the previous categories. They differ in that their application is confined to a specific object. The object information is the result of a small context application of a sensor. For instance, a temperature sensor used inside a machine provides object information which is different from an ambient temperature sensor.
The first classification is that of the ambient sensors. This category groups together sensors that monitor an environment’s characteristics and represent them in data. The most common are temperature, light, atmospheric pressure, and humidity sensors. A second group, motion sensors, collect the data from the movement of an entity. Accelerometers and gyroscopes are the main components of this group. In the most modern sensors, the axis varies from 3 up to 9 axes. A third class is the one for electric sensors which monitor information about energy consumption at a place. Those sensors usually are a multivariate data provider that analyzes current, tension, and other electricity-related data. An exception is the capacitance sensor, which might be used for interaction, position, and other applications.
Biosensors collect information from a living being, representing biological data to the system. Electrocardiogram (ECG), electroencephalogram (EEG), heartbeat, and breath sensors are the most common ones found in this category. Object identification sensors and their accessories (e.g., tags or cards) are used to identify an entity to the system. Furthermore, it is possible to store semantic data in the tag, in addition to the offered identification service. Among emerging identification technologies, we list RFID and NFC. Position sensors aggregate the geolocalization or spatial information about an entity. This family of sensors collects the position relative to a reference which can be global, as in the case of GPS, or specific, in an indoor wireless network localization service. This data ranges from simple coordinates to complex collections of data, as with GPS sensors. The most popular sensors used here are GPS, magnetometers, and fixed wireless access points through the processing of received signal strength (RSS) information.
Presence sensors became ubiquitous and very popular in the security context. Their main use is to detect if a person or animal is entering a predetermined area. The passive infrared sensor (PIR) is by far the most common example. More advanced machine vision-based sensors utilize computer-assisted vision to provide data to IoT platforms. The application might then detect movement, persons, or things through the use of image processing techniques. Chief among these sensors is the security cameras (conventional or infrared).
Interaction sensors are small gateways to conscious human interaction. Their objective is to capture human input from the environment and act accordingly. Physical buttons and sliders are examples of this group.
Acoustic sensors are sound-activated devices that gather sound wave data and send this to an application. Microphones and piezoelectric sensors are some examples of devices that perform acoustic sensing. Force/load sensors measure an external force applied to them. Load sensors and speed meter sensors are instances that fall into this category. Hydraulic sensors measure the properties of water and other liquids, including water level and its flow intensity. This group also includes important water quality sensors.
Other environmental sensors include chemical sensors that detect substances in the air. Smoke detector sensors, pH sensors, and gas sensors are further instances. Finally, object information sensors are a specific category of sensors that are devoted to providing information about a single object. Object information is a small part of the context application of a sensor. As an example, an application may prefer using a temperature sensor embedded inside a machine as opposed to relying on an external ambient temperature sensor.
Application analysis
The surveyed papers have also been classified according to their applications, reflecting the IoT system as seen from a consumer point of view. For instance, the case described in the introduction in which soil sensors are being used could then be classified as having a “smart agriculture” application. The categories for this analysis were not known beforehand, they were discovered from mining the sample’s papers. The main concern with those applications is finding a way that relates the sensors and the scenarios with an application. Note that one scenario can have different applications. Similarly, an application may be associated with scenarios with totally different configurations. We contribute by identifying such relationships and formally quantifying them in the section that describes our results.
Results
Our results are divided according to the following three main aspects: applications, scenarios, and sensors. The first one, namely, applications, elicits the classification for each application. Our findings regarding the scenarios summarize the analysis of the context of the “things” and the case variable values. Finally, the main characteristics of Internet of Things are discovered and presented.
Application results
We first built insights reflecting current IoT applications. From the 48 examined research papers, 15 applications were identified and listed in Table 4. Note that smart home is the most common application, followed by smart healthcare and smart city. The four most common applications are two times more popular than the 11 latter cases.
Table 4
Applications found, by the quantity of papers
Application
Papers count
Smart home
11
Smart healthcare
9
Smart city
8
Smart agriculture
4
Smart building
3
Energy monitoring
2
Playful furniture
2
Robot movement
2
Water management
1
Learning device
1
Disaster management
1
Smart vehicle
1
Smart security
1
Personal security
1
Personal information
1
Total
48
In fact, smart healthcare is a special case, as it is part of a home and a business environment (e.g., a hospital). Another notable application is robot movement. The surveyed works showed keen interest in sensor-based autonomic robots and human-controlled robot research using the IoT as an underlying architecture. The smart vehicle application had a low result in our sample. Most of the smart vehicle papers initially gathered adopted simulation to build their testbed and evaluations. This is mostly understandable due to the presence of a number of vehicular network simulators as well as the need to study the large-scale dynamics of traffic and vehicles. We also note some overlaps among the applications as was the case for example with the two applications energy monitoring and smart city. Smart city applications often included energy monitoring but on a city-wide scale. We observe a similar overlap between the IoT applications smart agriculture and water management.
Scenarios patterns
A paper, once analyzed, was evaluated and scored a degree in each of the scenario variables described in “Analyzed variables” section. The final IoT scenario score consists of a string made from the scores’ concatenation of each of the scenario metrics. For example, a scenario that has density = 1, mobility = 3, intensity = 0, heterogeneity = 1, area = 2, human interface = 1, and actuability = 0 will be represented as “1301210.” This notation is important in order to observe if any scenario is equal or close to any other one. Using this coding technique, it is straightforward to compare the distance (consequently also the similarity) between the scores of two scenarios. To achieve this, we simply sum the differences among the scores of each of the final scores. A weighted sum may be used in the future to differentiate among the impacts of these parameters.
Within our sample space, only three patterns of scenarios matched, i.e., scored the same string. Two of them were very simple (mostly composed of zeros) and close to themselves: patterns 0020000 and 0021000, each with two matching cases. There is also one with a complex pattern (1032102) with two matching cases. The other 43 scenarios were unique. However, they obtained very close scores, mostly with a single variable being different. To better understand this issue, a similarity table was built to comprehend how close the different scenarios are to one another.
The similarity table compares the columns (positions) of each scenario pattern (string) to the others. If a variable intensity matches, the scenario has at least one level of similarity. This research represents the level of similarity in percentages. For example, when a comparison has one variable with equal intensity, it is 14.3% similar. On average, the scenarios have at least two variables equal (similarity = 28.6%, see Fig. 1), followed by three variables (similarity = 42.8%), and just one variable (similarity = 14.3%). The pattern with least common variables was “1101133,” with 14 non-matching items. The most approximate pattern is “0020000,” with 5 matches with at least 85.7% similarity. The complete similarity comparison is presented in Fig. 1.
Fig. 1
Similarity average of the surveyed scenarios. The graphic shows that the majority of scenarios has at least two equal variables (28.6% similar)
×
Variable and scenario potentiality analysis
An important objective is discovering if each scenario is fully leveraging all the information provided by a variable for an IoT solution. In this section, the potential of each sampled variable will be analyzed, as well as each scenario total. This analysis is valuable to understand the criticality of the IoT solution. The higher average in each variable shows that the variable is present in the sample articles. Higher values in the case potential denote a more intense, data critical, and complex system (with more interaction with other actors).
As defined by the scenarios’ variables, each item can range from 0 to 3 for each analyzed aspect. So, the average of each variable score reflects the variable potentiality. Table 5 represents this data. “Intensity” was the variable most present, followed (by far) by “heterogeneity” and “density”. This intensity data confirms the big data identity of IoT. But some expected values, such as a higher presence of the “area” variable (as in smart cities or smart farms) were not significantly present in the sample. Furthermore, the “human interaction” and “mobility” got the lowest score. This leads us to believe that the IoT applications are mostly configured as a static and human-independent paradigm. The majority of the researched papers do not need human input or human interaction to function.
Table 5
Scenarios’ variable average and percentage of maximum score total from the sample
DEN
MOB
INT
HET
A
HI
ACT
Average
1.17
0.85
2.10
1.44
1.00
0.83
1.00
% of the max score
38.10%
27.89%
68.71%
46.94%
28.57%
27.21%
32.65%
Standard deviation
1.17
1.15
1.17
0.97
1.00
1.02
1.38
The scenario potentiality is composed of the sum of the variables’ values, compared to the maximum. As an example, the scenario “2012010” has 6 points in potential (2 + 1 + 2 + 1) or 28.6% of the case potential (the maximum would be 21 points). The majority of the cases’ potential is placed between 40% and 60%, as presented in Table 6. Many cases analyzed in this sample do not show a complex configuration (under 40%). Only one outline case has the potential over 80% (precisely 80.95%).
Table 6
Scenario potential, by quantity
Potential
Quantity
Under 20%
10
Between 20% and 40%
10
Between 40% and 60%
23
Between 60% and 80%
4
Over 80%
1
Total
48
Scenarios’ variables correlation
In this section, the correlation among the scenarios’ variables will be presented. As a first exploratory study of those variables, there is no pre-conceived hypothesis. The main idea is to show the variables’ inter-relations from this sample to be deeply researched and compared in future works.
The most significant correlation happens between density and heterogeneity (as seen on Table 7). These two variables and area seem to have tied correlation, as the three together also correlate (p < 0.5 and p < 0.01). Area and density are expected to be correlated, but the heterogeneity is a new perspective for the sample data. This information presents an IoT important characteristic from the sampled papers: the variability of sensors’ type and the quantity are correlated to the space.
Table 7
Correlation table of the scenarios’ variable
DEN
MOB
INT
HET
A
HI
ACT
DEN
Pearson’s r
–
− 0.140
0.250
0.592***
0.434**
− 0.137
− 0.052
p value
–
0.344
0.086
< 0.001
0.002
0.354
0.723
MOB
Pearson’s r
–
0.059
0.116
0.409**
0.416**
− 0.268
p value
–
0.690
0.431
0.004
0.003
0.066
INT
Pearson’s r
–
0.241
0.011
0.086
− 0.092
p value
–
0.099
0.939
0.560
0.534
HET
Pearson’s r
–
0.299*
0.011
− 0.207
p value
–
0.039
0.942
0.158
A
Pearson’s r
–
− 0.229
− 0.061
p value
–
0.117
0.679
HI
Pearson’s r
–
0.030
p value
–
0.838
ACT
Pearson’s r
–
p value
–
*p <.05,
**p <.01,
***p <.001
Mobility and area are also strongly correlated. This is another expected result, as the ability to change places happens in scenarios that support great areas. If the sensors are hard-bounded to an area, the mobility would be low. Mobility is also strongly related to human interface. This is another foreseen result, as the ability to change areas is mostly done by humans. The sensor’s or machine’s movements were not so present in the sample.
Actuability and intensity were poorly correlated variables from this sample. These two variables seem to have a constant value: high values for intensity and low for actuability. Table 5 can help to explain this, as intensity has a higher average and actuability has a small average and greater deviation.
Sensors’ analysis results
In this section, the sensors’ quantity and use will be examined. As presented in Tables 8 and 9, the great majority of the surveyed sensors were from the ambient classification. Temperature, light, and humidity sensors are the most commonly found sensors across our sample, all under the ambient category.
The most common temperature sensors are semiconductor sensors and thermocouples. The first is easier and cheaper to build and use. An example would be the TMP35 sensor, which ranges from −70 to +125 ∘C. The latter needs a digital converter but has wider temperature range. The MAX31855 cold-junction compensated thermocouple-to-digital converter, for instance, can handle a thermocouple from −270 to +1800 ∘C.
Humidity is commonly measured relative to ambient temperature (relative humidity will be discussed also in the “Validity threats and restrictions” section). A humidity sensor is usually combined with a temperature sensor (as in the D-Robotics DHT11). There are some absolute humidity sensors, but none were clearly presented in any article in the sample.
Light sensors are present in both indoor and outdoor applications. The most ordinary light sensor consists of a photoresistor (found in the CDS’ photoconductive photocell gl5528). But it also contains some phototransistor components (as in the Vishay’s TEMT6000). Some components can also split the light into the spectrum (red, green, and blue) to analyze color (an example would be SparkFun’s RGB Light Sensor ISL29125).
Accelerometers are popular motion sensors built-in to many devices (as smartwatches or smartphones). Such sensors can also be embedded in small IoT Arduino or Raspberry Pi boards. The most common sensor is a 3-axes sensor, but the most modern ones support up to 9 axes (combined with gyroscope and compass). RFID and NFC are very common in the IoT solutions. They are used under the identification category. The passive infrared sensor (PIR) is an affordable presence sensor encountered in many scenarios. The low cost and ease of use for PIR sensors are reflected by their presence in six scenarios from three applications in the sample.
The electric category unites sensors that get data from the power grid. Energy variables such as tension, current, and energy consumption are some examples of data from this group. Those sensors also might have a characteristic presented in the “Validity threats and restrictions” section, in the form of a validity threat. Beyond the energy measurement, capacitance and soil conductivity were present in the sample. Those sensors are used in user interaction (such as in playful furniture) and smart agriculture, respectively.
From the sample, the Biosensors were well represented. This category does not have just one popular sensor; it has a lot of variety. The most frequent sensors are heart-related, such as in the electrocardiogram (ECG), heartbeat, and blood pressure sensors. But one remarkable one was the electroencephalogram (EEG), which aims to enhance human interaction through brain waves. Another curious finding from Tables 9 and 10 is that the smart healthcare has fewer biosensors than other kinds of sensors. The healthcare application is using motion, identity, ambient, and presence sensors to provide real monitoring for patients or the elderly (see Fig. 3 for a better understanding of this relationship).
Table 10
Total of sensors by each application
Application
Sensors
Smart healthcare
28
Smart home
28
Smart city
23
Smart agriculture
13
Smart building
9
Smart security
8
Personal information
7
Playful furniture
5
Smart vehicle
4
Water management
4
Robot movement
4
Personal security
3
Energy monitoring
2
Learning device
2
Disaster management
2
Total
142
Applications, scenario, and sensor relationship
Once we classified the application, scenarios, and sensor characteristics, we looked into the relationship between them. Figure 2 shows a graph connecting the scenarios with different types of sensors. The graphs from this work were generated using Gephi 0.91 for Linux. The organization layout used was “Force Atlas 2,” with scaling set to 210. The graph is directed. It is composed of 118 nodes and 190 ties, with average degree 3.22. Green nodes depict scenarios, purple nodes represent sensors, and orange nodes are the scenario’s application. The presence of lines connecting a scenario to one or more sensors shows that this scenario uses that sensor.
Fig. 2
Applications, scenarios, and sensor graph. Each node represents either a sensor (purple node), a paper’s scenario (green node), or an application (orange node)
×
As defined by the layout, the more connected nodes are placed in the center of the graph, the lesser the connection on the periphery. When the graph has repeated scenarios, a letter “A” was appended to avoid miss-reference (as in “0021000” and “0021000A,” water management and smart home, with totally different sensors).
The scenario “2133030” is the node with most diversity of sensors (10), followed by “3032203” (8), “2023200,” and “3333320,” both with 7 sensors. Those scenarios’ applications are, respectively, smart healthcare, smart security, smart agriculture, and personal information. From the top application in Table 4, only smart healthcare and smart agriculture match the most sensing scenarios. The scenario potentiality rank was closely related to the quantity of sensor rank, but not defined by it. The potentiality did not correlate to the quantity of sensors, as seen in Table 11.
Table 11
Pearson’s correlation of sensors’ quantity and scenario’s potential
Potentiality
Sensor’s variety
Pearson’s r
0.361
p value
0.011
There is no significant correlation from the sample
From the sample, 14 scenarios have just one sensor each. The applications with least and most variety of sensors by scenario are described in Table 12. From the top sensing sample, four applications are also in the bottom sample. This table shows that there is no relationship between the variety of sensors and application. The scenario might have only one data source, but still in the same application domain.
Table 12
Applications and scenarios, classified by the most and least variety of sensor
Application
Scenarios
Bottom sample (1 sensors)
Smart city
3
Smart healthcare
3
Energy monitoring
2
Smart home
2
Playful furniture
1
Robot movement
1
Smart agriculture
1
Smart building
1
Total
14
Top sample (> 5 sensors)
Smart city
2
Smart healthcare
2
Personal information
1
Smart agriculture
1
Smart building
1
Smart home
1
Smart security
1
Total
7
For further analysis, this graph is available as an interactive HTML5 page generated by the SigmaExporter, from the Oxford Internet Institute. You can explore it in the references of “??” section.
Sensors and applications relationship
In this section, links between sensors and their applications will be identified and depicted. In Fig. 3, an orange node represents an application, a purple one represents a sensor, and a green node represents the sensor’s type. This graph shows the way each sensor is used in the final application and which sensor and sensor’s type are more popular or commonly used in each application. Each line represents a connection between a sensor and an application or a sensor and a sensor’s type. The line’s thickness represents the degree of presence of this sensor in the application. If this number is above 1, it is presented in the middle of the line.
Fig. 3
Sensors, sensor’s type, and application graph. Each node represents either a sensor (purple node), an application (orange node), or a sensor’s type (green node). Each application can gather one or more papers from the sample. The line width represents the amount of the sensor in the application. When the presence is over 1, the number of sensor is presented in the middle of the tie
×
The smart home is the application with the most variety of sensors (18 types), followed by smart healthcare (17 types) and smart city (16 types). From the sample, the smart home and smart healthcare have the same quantity of sensors, as seen in Table 10, but the smart home has more variety. Temperature, humidity, and accelerometer are the most used sensors (respectively 8, 7, and 6 applications), followed by light sensor and RFID. The light sensor is used by smart agriculture, smart city, smart security, smart healthcare, smart home, and personal information applications. RFID is still an important sensor in many application and is more used than the NFC in this sample. The GPS sensor, on the other hand, is only connected to two applications, namely, personal security and smart healthcare. The smart healthcare’s most predominant sensor is the accelerometer. This might be related to the great variety of heart monitoring devices, but it is an interesting fact that a motion sensor is a prominent source of e-health data.
This graph also is available as an interactive HTML5 page. You can explore it in the references of “??” section.
Conclusions and contributions of this work
This work proposes a method to classify and compare IoT scenarios. The authors believe that this is the first time sensor, scenario, and application have been inter-related for IoT systems.The first contribution is the classification scheme presented in the analysis (“Scenarios’ variables” section). This codification will help developers and data analysts to better understand what the characteristics of an IoT application are. Also, developers and/or data analysts can match and compare those codes as a parameter to an existing product.
Our main contribution presents insights from current IoT applications. From the 48 examined research papers, 15 applications were identified. They are listed in Table 4. Note that smart home is the most common application, followed by smart healthcare and smart city. The four most common applications have two times more papers than the 11 latter cases. One interesting fact found from this sample was that there is no relationship between the variety of sensors and applications. The scenario might have only one data source, but still might be in the same application domain.
Another contribution is the discussion of the state-of-the-art of sensors in scientific papers. As presented in Tables 8 and 9, the great majority of the surveyed sensors were from the ambient classification. Temperature, light, and humidity sensors are the most commonly found sensors across our sample, all under the ambient category.
In the future, we may think of code-related templates that would give developers and researchers a jump-start in the design and evaluation of IoT applications. As an example, a developer designing an IoT system for a water metering scenario with the pattern “2012010” may be given references and guidelines on how to achieve their task. The developers may also find out the amount of effort needed to translate the water IoT system to another application (such as electrical) by simply comparing the scenario’s code difference (especially if they have the same or very close pattern code). We believe that the proposed codification scheme facilitates both the understanding and the comparison of IoT applications.
Validity threats and restrictions
The present work has an internal validity threat as presented by [16]. This threat appears from the imprecise presentation of sensors in the papers. In some cases, two data sources (e.g., humidity and temperature sensors) are bundled in the same device. Humidity is commonly measured relative to temperature, so temperature and humidity are measured from the same sensor. But when presented in the paper, some authors from the sample did not specify if the produced data (humidity and temperature) are from one sensing device or two. So, for the sake of precision, those cases were represented as different sensors. The number of those sensors may be higher or lower than the presented number, but without the author’s better specification of the actual instruments used (as a list of sensors used), it is impossible to determine the correct numbers. This phenomenon might happen in the electric sensors (as current, tension, and power consumption might be included in an AC analyzer) and in biosensors (all heart-related sensors might be an ECG). One suggestion to enhance future IoT works is to present a clearly defined section describing the instruments used, in the main text or appendix, describing sensors used, manufacturer, and model. This information would improve the precision of sensors’ variable data types and quantity.
Another threat might have to do with work validation. But, as a first IoT scenario experimental classification, this threat is expected. The classification presented in this work is likely to be expanded, enhanced, be better defined, or changed after the publication. The nature of IoT might demand modifications that could not be predicted at the time of this writing.
The main restriction of this work is the sample’s publisher source quantity. The authors understand that a great variety of sources would provide a better overview of the IoT scenario. But this paper chose a qualitative analysis, so each paper was a semantic trial, to avoid imprecise selection of paper. We invite other authors to apply the same method to other paper sources, in order to complete this overview.
Appendix 1: List of surveyed papers and classifications
Table 13
Complete list of surveyed papers, with scenario code and application classification
Note: The exporter redraw the network, so the layout might be different from the version presented in the static figures. But both are from the same Gephi’s dataset.
Ethics approval and consent to participate
Not applicable.
Consent for publication
Not applicable.
Competing interests
The authors declare that they have no competing interests.
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
The concept of actuability is close to the one defined in [17], but extended beyond the motion ability of motors. In this work, actuability is seen as the capability of a thing or a system to act on someone/something else.
