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].

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.

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
Full size table

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 scenariosFootnote 1. 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 actuabilityFootnote 2).

Table 2 Scenarios’ variable description and quantifier
Full size table

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’ analysisFootnote 3. 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
Full size table

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
Full size table

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
figure 1

Similarity average of the surveyed scenarios. The graphic shows that the majority of scenarios has at least two equal variables (28.6% similar)

Full size image

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
Full size table

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
Full size table

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
Full size table

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.

Table 8 Sensor list by quantity
Full size table
Table 9 Sensor quantity, qualified by kind
Full size table

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
Full size table

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
figure 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)

Full size image

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
Full size table

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
Full size table

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
figure 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

Full size image

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
Full size table

Appendix 2: List of sensors from the sample

Table 14 List of all sensors found in the sample
Full size table