As stated in Section 2.2
, after we extracted data for 718 papers, we decided to limit our search scope to well-known publishers, which led us to download and analyze 353 papers. Moreover, after applying the inclusion and exclusion criteria (see Section 2.3
), 221 papers were selected for the final review. We want to highlight that 59 papers categorized under no explanation
are not included for the final review, as these papers did not provide any insights related to our study aim. Below, first we present the distribution of papers and some demographic data, and based on comparative analysis we address the research questions stated in Section 2.1
3.1. Distribution of Papers
In the final review, as introduced above, we decided to classify and map the papers into five categories, i.e., use, indicate, propose, define
and no explanation
(for details about categorized papers see (http://doi.org/10.5281/zenodo.3755257
)). The result of the classification process is presented below, such that:
It is interesting to note that majority of the papers make use of open IoT platforms, plenty indicate or provide no explanation, and only three papers make an attempt to define what an open IoT platform is. In particular, we noted the large number of papers that mention open IoT platforms term but they do not
provide explanation or give deeper insight; often by making use of the term superficially within the introduction, related work or future work sections. Driven by this finding, we decided to further analyze and quantify the distribution of the published articles with no explanation, which is presented in Figure 2
. Among other things in Figure 2
, we noted the openness trend
that relates to open IoT platforms and that has significantly increased between 2016 and 2019 by number of published articles that do not
provide explanation. As a comparison, Figure 2
also shows the total yearly publication distribution of the selected 221 articles. It is obvious to see the openness trend
between the same years, 2016–2019.
shows an increasing trend for publishing open IoT platform-related papers. One factor of this trend, we believe, is the emerging interest of research in the use of openness in the IoT domain in recent years. These findings, to an extent, correlate well with the report of IoT analytics that is one of the leading providers for providing market insights and strategic business analytics for Industry 4.0 and IoT, stating that 450 companies created their IoT platforms in 2017, which is 25% more than in 2016, and that there is a tendency for this trend to increase even more over the coming years.
3.2. Q1: What IoT Platforms Have Been Characterized as Open?
To address this question we analyzed the data extracted from F7 and F8 stated in Table 1
, i.e., open IoT platforms in “use” and “indicated”. Table 2
reveals that there are 25 IoT platforms characterized as open by the studies. We note that there are seven open IoT platforms that are mainly used within the research community, whereas the other platforms are used only once or twice. For example, Figure 3
shows that most used open IoT platforms are NodeMCU and ThingSpeak, which together held a share of more than 70%, and are followed by FIWARE, Mobius, Kaa, OpenIoT, and ThingsBoard.
Moreover, there is an interesting correlation between the referred open IoT platforms when they are “use” versus “indicated” by the researchers and practitioners, which is presented in Figure 4
. In particular, we noticed that the researchers who make use of NodeMCU often do not refer to it as an open IoT platform; however, this is the case as soon as they are providing a description of it. We note that on Wikipedia, NodeMCU is referred to as an open-source IoT platform
; however, its official homepage refers to it as an open-source firmware and development kit
, which we think is an interesting observation and we agree with the latter. This also outlines that researchers tend to get more easy information from the web.
Furthermore, OpenIoT is mainly used by partners and researchers that were part of the project ICT OpenIoT Project FP7-ICT-2011-7-287305 and that its GitHub repository has received no updates since November 2015, which by coincidence correlates well with the end date of project (28 February 2015) as stated by the grant agreement. The requirement of the IoT platform being ready to use and having an active community has gained momentum and become a key criterion in order to be identified as an IoT platform. By coincidence, platforms that either have not had their code updated since December 2015, or with no activity on their website during the same period of time, are considered no longer under active development and therefore do not satisfy the requirement to be identified as available
IoT platform [32
3.3. Q2: Which Are the Openness Types of IoT Platforms?
To answer this question, we used fields F7–F11 from Table 1
. From the classified data we were interested to find out what makes the open IoT platform. However, from the F9 field, only three studies provided some directions of openness definitions related to IoT platforms [33
]. The first study proposes an open IoT service framework [33
]. Within this proposal, the authors define their open IoT platform by the following categorization: Device Platform:
for connecting and cooperating things with open IoT platforms; Planet Platform:
for server related aspects; Mashup Platform:
for new integrated services and devices to be available over the Internet; and Store Platform:
an online store including applications or links for user services.
Even if the authors claim that they define an open IoT platform [33
], there is no clear definition of openness as such.
A very close study related to openness dimensions of platforms, specifically addressing industrial Internet platforms, was analyzed by Menon et al., 2019 [34
]. This study provides insights regarding the differences in the degree of platform openness, for instance how open the platform is in terms of the involvement of third-party developers. This involvement varies based on several aspects: (1) the access to information; (2) the rules that allow the usage of a platform; and (3) fee (license fee). The openness dimensions are defined in terms of: Demand-side user (end user), Supply-side user (application developer)
and Platform-provider-and sponsor-related openness.
The more open the platform is related to these three dimensions, the more easily different parties can use that platform.
Even if the authors [34
] provide different insights related to openness dimensions of platforms, they do not explicitly define what is an “open” IoT platform. However, an interesting insight out of this study [34
] is that stakeholders can play an important role for this matter, thus we bring the stakeholders view later in discussion part of our paper.
The third study by Asemani et al. [35
] presents some directions towards understanding IoT platform definitions in general by discussing the main characteristics. In this study, [35
], specifically they present high-level features of the open-source projects, such as connectivity/device management, data storage and management, data analysis, data visualization, development tools and platforms, edge/fog computing, integration and interoperation as main characteristics for open-source projects related to IoT platforms.
Even if the authors [35
] provide and place several open-source projects into different characteristics, they do not provide the openness definition and neither the openness types of IoT platforms.
Further on, we analyzed extracted data from F7, F8 (134 used and 56 respectively indicated) and F11. Table 2
shows 25 open IoT platforms that are mapped with the identified openness types. Among them the most common denominator is open-source. For example, 45 studies mark NodeMCU as open-source, and respectively 29 for ThingSpeak. We can consider each openness expression of the different open IoT platforms as a vote for what makes them open, because the specific IoT platform is referred to with different openness types based on author opinions. With Figure 5
we observe that most of researchers consider open IoT platforms from an open-source perspective. Interestingly, for ThingSpeak there are 12 papers in which the authors do not specify the openness type, but just mentioning ThingSpeak as an open IoT platform. Other identified openness types based on “used and indicated” categories of papers are open standards, open APIs, and open data, and some of the papers analyzed do not even specify the openness type of the platforms they use. It is important to highlight that some papers refer to open data in Table 2
for example as compared to open layer as is presented in Table 3
under proposed platforms. Open data we believe leans more toward open standards and sometimes open APIs for example to access data from ThingSpeak, OpenIoT, or FIWARE platforms.
Moreover, we analyzed the data extracted from F10—“open IoT platforms proposed” Table 1
. Overall, the data from the proposed category of papers shows that their IoT platforms are open. However, we were interested to find out what new open IoT platforms are proposed beside the ones identified under “used and indicated” in Section 3.2
and what is their interpretation related to openness
types. Thus, overall, the openness types (F11) are derived and categorized from the studies that “used”, “indicated” and “proposed” the open IoT platforms, for details see Table 2
and Table 3
. Among the 28 papers proposing open IoT Platforms, 21 “Proposed Platforms” are offered, and six do not provide a name of the platform (indicated with authorship in Table 3
). Based on explicit statement from the papers, interestingly only eight IoT platforms are defined as open IoT platform because of open-source as shown in Table 3
, whereas five are because of open standards, another five are related to open APIs, and four are related to open layer. Based on the observation from the analyzed data from the studies, the open layer is intended to integrate different third-party software. However, this kind of functionality could also be provided mostly by open APIs. Compared to open layer, open APIs usually have a more formal format to access and invoke them. Moreover, most of the open APIs can be treated as open layer, but not the opposite. Two studies mention openness in terms of open service and the use of Blockchain as an open database, thus are mapped as Not Specified
in Table 3
. Some platforms have overlapped openness types, like bIoTope, with both open standards and open APIs.
The above openness types are directly extracted from the collected papers in this study. However, to understand the different openness types further, we explain them as follows:
Reflecting on our study, we observe that open-source is the most widely accepted openness type as it is more convenient for third-party developers to have a full access to the source code. Open standards, such as that on which FIWARE is based, has some overlap with open APIs; however, they are usually used under different contexts. For example, FIWARE has a FIWARE-NGSI version 2 API in its specification, which is intended to manage the lifecycle of the context information. Moreover, the FIWARE open APIs are slightly different from the ones provided by ThingSpeak; for example, FIWARE APIs are part of the open standards.
Another interesting observation is gleaned by looking at Table 2
and Table 3
, which reveal that 1 out of 21 proposed open IoT platforms are not widely used ones, besides the OpenIoT platform. This is mainly because the OpenIoT was a funded research project which was mainly used by the involved partners.