What Is an Open IoT Platform? Insights from a Systematic Mapping Study

: Today, the Internet of Things (IoT) is mainly associated with vertically integrated systems that often are closed and fragmented in their applicability. To build a better IoT ecosystem, the open IoT platform has become a popular term in the recent years. However, this term is usually used in an intuitive way without clarifying the openness aspects of the platforms. The goal of this paper is to characterize the openness types of IoT platforms and investigate what makes them open. We conducted a systematic mapping study by retrieving data from 718 papers. As a result of applying the inclusion and exclusion criteria, 221 papers were selected for review. We discovered 46 IoT platforms that have been characterized as open, whereas 25 platforms are referred as open by some studies rather than the platforms themselves. We found that the most widely accepted and used open IoT platforms are NodeMCU and ThingSpeak that together hold a share of more than 70% of the declared open IoT platforms in the selected papers. The openness of an IoT platform is interpreted into different openness types. Our study results show that the most common openness type encountered in open IoT platforms is open-source, but also open standards, open APIs, open data and open layers are used in the literature. Finally, we propose a new perspective on how to deﬁne openness in the context of IoT platforms by providing several insights from the different stakeholder viewpoints.


Introduction and Motivation
After decades of development, the Internet of Things (IoT) has evolved into a fully fledged ecosystem including hardware, software, physical objects and people with complex interactions and data exchanges. The number of users, services and applications with IoT is rapidly growing in many different domains [1]. The development of new intelligent applications can benefit from IoT in almost every field from personal everyday life to environment and society. Borgia [2] classifies the various IoT applications into three major domains-industrial domain, smart city domain and health well-being domain-and gives many related applications as examples such as farm management [3], smart grid [4], and remote healthcare [5]. Because of the huge potentialities in IoT, the demands for new services and applications are massive.
The IoT market is predicted to grow, by some estimates, from 50 billion [6] to 100 billion [7] devices by 2020. Other more modest projections state that there will be 24 billion [1] and 26 billion [8] devices by the same year. The large number of devices builds a solid foundation as the device layer. Numerous services and applications can be further developed based on devices with many different technologies [9]. However, such a scale of devices and various enabling technologies make the development of IoT systems complicated and difficult. For these issues, IoT platforms play a significant role in helping the integration and development of IoT systems.
As a result, new IoT platforms are constantly emerging, which forms a new layer in Cyber-Physical Systems (CPSs) [10]. These IoT platforms already offer heterogeneous ways to access them and their data [11]. According to the Minerauda et al. [12] an "IoT platform is defined as the middleware and the infrastructure that enables the end users to interact with smart objects". There are different types of platforms available that often are referred to as IoT platforms, such as device-to-device, cloud-based and device-to-cloud platforms (which are often also referred to as enterprise platforms that face a vendor lockdown [13][14][15]). The diversity of IoT platforms and their complex offerings creates confusion among developers and researchers, as well as end users. As such, today the IoT is mainly associated with vertically integrated systems that often are closed and fragmented in their applicability. For example, there are multiple IoT platforms, which partially comply with standards; diverse mobile platforms and systems, where the operating systems and programming languages are different; and physical devices that have varying characteristics [11,16]. With such closed nature and fragmentation in the market, developers usually struggle to reach critical mass, and even end users need to navigate through different brands and understand which devices are compatible in relation to which IoT platforms. Commercial or proprietary IoT platforms carry a pricing model and often promote vendor lock-in. Thus, often IoT platform providers lack support of new protocols, tools and data formats in time due to a constantly changing IoT landscape. Openness, on the other hand, is one of the emerging trends that is evident in IoT domains [16][17][18]. More and more IoT players are motivated to use open systems due to the associated benefits such as convenience and fast development resulting in major cost savings for the industry [17,19]. From a general perspective, innovation, entrepreneurship, creativity and new business models also require openness to build a valuable ecosystem based on our previous experience in the Internet economy [20].
Several interesting studies provide analysis of some open and closed IoT platforms [12,[21][22][23][24]. A study on gap analysis of IoT platforms lists a representative sample of both open and closed ones, providing an overview of actual platforms, their heterogeneity, type, deployment architectures, availability and data access [12]. Another study focuses in surveying IoT platforms for massive sensing and actuation, and discusses some of the platforms and mainly ideas about how they work, including strengths and weaknesses [25]. A survey of IoT cloud platforms is also provided [21], while identifying suitable middleware platforms to manage things and applications with a reliable solution [22]. In two other studies, three open-source platforms and one proprietary are compared while discussing concepts, similarities and differences [23,24] Below we highlight the contributions of our study: 1. We provide a comprehensive overview of the "open IoT platforms" to the research community via a systematic mapping study. Openness as trend has significantly increased during recent years. One factor of this trend is the emerging interest of research in the use of openness in the IoT domain. 2. We identified 46 IoT platforms as "used", "indicated" and "proposed" from 221 analyzed papers.
We highlighted the seven most used open IoT platforms. We note that NodeMCU and ThingSpeak are widely adopted platforms among the research community with the biggest share, followed by FIWARE, Mobius, Kaa, OpenIoT, and ThingsBoard. IoT platforms into six openness types: open-source, open standards,  open APIs, open data, open layer and not specified with emphasis to understand why the IoT platforms  are known as "open". We also note that some papers express the same open IoT platform with  different openness types, while the most dominant openness type labeled among the analyzed studies is "open-source". 4. Finally, we propose a new perspective on how to define openness in the context of IoT platforms by providing several insights from the different stakeholder viewpoints, which interprets the differences among all the papers' different expressions of the openness of IoT platforms.

We map all the identified open
The rest of the paper is organized as follows. In Section 2, we discuss our research method. We present the obtained results and analysis from the selected studies in Section 3. Thereafter, we discuss the results of our review (Section 4), followed by some limitations highlights (Section 5) and finally we conclude the study (Section 6).

Research Method
In our study, we use a systematic mapping study which consists of planning, conducting and reporting as proposed by Petersen et al. [26]. During the planning phase, all decisions for conducting the mapping study are made, such as defining the scope and research questions. Review protocol is established by the team, which describes the procedure to conduct the study [26]. In the conducting phase, first, studies were selected and then data was extracted and analyzed. This phase was iterative [26]. In the reporting phase, the study results were summarized and reported [26]. The most important part of systematic studies is the planning phase of the review protocol to ensure rigor and reproducibility of the study [27]. In our review protocol, we identified the research questions and a search string, then we used the manual search in our strategy that led us to define the search scope. During this step we performed pilot searches then we developed inclusion and exclusion criteria. The pilot searches helped us to refine both the search strings and the criteria. Finally, relevant publishers in the IoT field are used as data sources.

Research Questions
The goal of this study is to characterize open IoT platforms from the researcher point of view. We use a Goal-Question-Metric (GQM) approach to classify our goal with aspects of purpose, issue, object and viewpoint [28]:

Search Strategy and Sources
The search strategy is composed of different steps. At first, we performed some trial searches in IEEE and ACM digital libraries by trying and testing different search strings in relation to RQs. However, to get more accurate results, we decided to use Google Scholar as it was better to query and filter our data. After some additional trial searches, we defined the following search string: We used Publish or Perish [29] to easily retrieve the data from Google Scholar and have them in a format suited for analysis. Based on the above search string, we retrieved the data until our last conducted search on 30 September 2019 that included 718 papers. However, we note that based on our search string the earliest published papers related to open IoT platforms start from 2012.

Inclusion and Exclusion Criteria
Inclusion and exclusion criteria helped our team to identify and classify the studies based on our research questions. The papers were selected if they strictly met any inclusion criteria and thus were classified, and were excluded if it met any exclusion criteria. The following inclusion criteria were applied: The following exclusion criteria were applied: 1. Tutorials, BSc/MSc thesis, editorials, opinions, abstracts only, because they might not contain sufficient data for our study.

Studies not written in English 3. Open IoT platform mentioned only in references
For inclusion criteria 4, we limited our search scope to the sources and databases that are well-known in the IoT field related to publications: One of the main reasons for choosing these sources and databases was based on the suggestions of Brereton et al., [30] and Dyba at el., [31] to perform more exhaustive searches in our field of study. Having in mind that IoT publication venues are still developing, additionally we used other sources as well: IET, and • SAGE Publications.
After applying the above limitation based on publications and language where we started to apply the inclusion and exclusion criteria, we obtained 353 papers that we then downloaded and analyzed them (see downloaded studies (http://doi.org/10.5281/zenodo.3755257)). Figure 1 shows our search process where we used initial and trial searches (1.1) to identify the topic relevancy, and to define the final search for stage 1.2 query. Further on, inclusion and exclusion criteria (stage 2) are continuously applied which led us to the final review and analysis at Stage 3. The data is collected and classified based on studies that: "use", "propose", "define", "indicate" or studies with "no explanation" in relation to open IoT platforms, explained below: By define, we mean the papers that attempt to provide a definition of the openness aspects of platforms.

•
By the studies with "no explanation" we mean the papers that use the term open IoT platform but with no further explanation, e.g., the term used in introduction, background, related work or anywhere including the conclusions within this category of studies.  Three researchers in parallel were involved in this process. During the process, the researchers discussed their findings and viewpoints with two additional researchers for validity purposes of the overall study. Moreover, all five researchers met regularly. To minimize the threats of our study, during the classification and mapping process ambiguity was addressed among the team, e.g., the challenges a researcher faced when mapping some studies in defined categories. During these meetings, all disagreements were discussed and resolved. In Table 1, we enlist the data extraction items and their relations with RQs. Open IoT platforms in "use" RQ1, RQ2 F8 Open IoT platforms "indicated" RQ1, RQ2 F9 Open IoT platforms "defined" RQ2 F10 Open IoT platforms "proposed" RQ2 F11 Openness type in "use", "indicated" and "proposed" Platforms RQ2 F12 Open IoT platforms with "no explanation" RQ2 The data is stored in online spreadsheets (to ease the collaboration and ensure reproducibility of the study) and was manually reviewed. Mainly qualitative data is collected but also some quantitative such as number of citations, published year, published venue in order to derive some basic descriptive statistics that can be used to address the RQs or other intermediate hypotheses that arose during the process.

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

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. Figure 2 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.

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

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][34][35]. 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.
Observation: 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.
Observation: 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.
Observation: 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 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. Figure 5. How many times the researchers express a platform as one openness type for the 25 identified IoT platforms in categories "used" and "indicated" among 221 papers. 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 Tables 2 and 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 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: Open-Source has already created a big ecosystem and innovation in the IT industry in general and beyond. The Open-Source Initiative (OSI) provides a clear definition with regards to ten requirements in order to decide what constitutes open-source, for example including free redistribution and accessing source code in terms that anyone can inspect, modify, and enhance it by complying to some basic principles [42]. Moreover, open-source can affect the industry to move faster towards open innovation with the benefit of reducing development costs [12,43]. Open Standards have a wide range of meaning associated with their usage, whereas we refer to a joint definition from the IEEE (Institute for Electrical and Electronics Engineers), ISOC (Internet Society), W3C (World Wide Web Consortium), IETF (Internet Engineering Task Force) and IAB (Internet Architecture Board). The open standards require five key principles, including cooperation, collective empowerment, availability and voluntary adoption to serve products and services targeted for different market requirements [44]. Open standards are primarily important to provide the support for heterogeneous devices to enable better interoperability [12]. Open APIs are publicly available application programming interfaces that provide developers with programmatic access to a proprietary or open software application or to a web service [45]. Open APIs are usually used by third-party developers. Open Data should be freely available to everyone to use and republish as they wish, without restrictions from copyright, patents or other mechanisms of control [46]. Open Layer is a technical description rather than a formal term. Based on the context of the related papers, the open layer is considered to be a software layer of the platform that is open for third-party software integration.
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 Tables 2 and 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.

Discussion
Our results show that there are 25 IoT platforms characterized as open which are categorized under "used" as presented in Table 2. Additionally, 21 IoT platforms categorized under "proposed" as presented in Table 3 are also characterized as "open", summing up to a total of 46 identified open IoT platforms from this study. In general, the type of openness is more evenly distributed. These platforms are used in different domains and implementations, and the most commonly used are NodeMCU and ThingSpeak. Our study also suggests that the most common openness type is open-source, but also open standards, open APIs, and open layers are used in the literature. Furthermore, we take this analysis one step further by investigating the different openness types.

Open-Source vs. Openness of IoT Platforms
As we reflected in Section 3.2, it was interesting to see that the researchers refer to NodeMCU as an open IoT platform. Based on this observation, we decided to study the homepages of the respective IoT platforms in order to compare their self-descriptions (Accessed online 16 April 2020), including the availability requirements, which are provided in Table 4. First, it is worthwhile to mention that five from the seven most used IoT platforms use the term platform on their homepages. In relation to this, we note that the self-description of NodeMCU states that it is an open-source firmware and development kit and not that it is an open-source IoT platform. Second, we note that the term open-source is not used for the ThingSpeak and KAA platforms. In relation to this, it is interesting to note that both started as open-source but then moved to the PaaS model with pricing options. However, it is also important to note that the available community edition from KAA has an active community and does fulfill the availability requirement from [32], whereas this does not apply to the open-source version of ThingSpeak, whose codebase has not been updated since November 2015 on GitHub. Even though ThingSpeak is still referred to as an open-source IoT platform, it is mostly used as an open IoT platform from an open APIs perspective. Rather than reusing the source code, most developers use ThingSpeak as a service, e.g., under the paid license options provided by MathWorks. FIWARE is in a similar situation, where even though it is open-source, it is mostly used as an open standard. Reflections such as these have been encouraged in the literature, for example in [47]. Third, note that the terms middleware and firmware or development kit are used to refer to OpenIoT and NodeMCU, respectively. See [48][49][50][51] for more information regarding what IoT middleware and IoT platform should accomplish, respectively.

Defining Openness of IoT Platforms?
Another result of our study is that there are no clear definitions related to the openness of IoT platforms. One of the papers attempts to define the platform aspects only [33], another paper categorizes the openness dimensions of platforms [34], and a final study categorizes some open-source platforms but without providing a definition [35]. Thus, none of them explicitly define what an open IoT platform is. Moreover, in our study we were also interested to identify the openness types of IoT platforms. Our results suggest that the most common openness types of most IoT platforms are related to open-source. Other types identified are open standards, open APIs, open data and open layer-based platforms. However, to further investigate the openness types of IoT platforms we believe it is important to look from a stakeholder view, as identified above [34,52]. Thus, it is essential to further analyze how important these openness types are from different IoT stakeholder perspectives.
Some of the most prominent key stakeholders within the IoT ecosystem are categorized as platform providers, application providers, device providers, system integrators and operators [52]. Platform providers deliver IoT products and services including IoT enabling capabilities, integration with third-party devices or applications, analytics and so on. Application providers usually provide more domain-specific solutions and applications. System integrators support end-to-end integration as well as testing. Device providers offer embedded devices, sensors, smart devices and appliances and so on [52]. Finally, operators provide the network infrastructure and connectivity.
Based on our study results, presented in Tables 2 and 3 [51]. Moreover, application providers often focus on core developers, third-party developers and data aggregators [34]. Thus, we observe that open APIs and open standards are important openness types for application providers. System integrators usually deal with complex IoT offerings with many moving parts including sensors, devices, connectivity, platform, business logic, applications and users [52]. Thus, system integrators play a unique role to provide end-to-end IoT solutions by integrating different parts, including the open IoT platform. The openness type of an IoT platform for system integrators could be different depending on how the IoT platform is used to deliver final solutions. The system integrators must consider multiple devices and technologies. If the system integrator concerns compatibility primarily, the open standard will be more critical openness type than others. An open standard can help the system integrators to decrease the switching cost to build a better ecosystem in many fields, i.e., in avionics [56] and in robot controllers [57]. From an implementation perspective, open layer, open APIs and open-source could also be considered for system integrators but always depending on their requirements. For example, if the system integrators provide their own IoT platform as a solution, then open-source is significantly more important openness concern. The availability of the source code control allows a system integrator to extend its offering in the areas of support services and it gives the system integrators more business potentials [58]. Thus, we observe that open standards and open-source play a significant role for system integrators. Device providers Compatibility is an essential concern for device providers to support different IoT   • Since none of the analyzed papers define openness, identifying openness dimensions of IoT platforms remains a challenge to be addressed.

•
It is of utmost importance to find a consensus regarding openness among the different stakeholders to avoid confusion, and preferably agree on a formal definition.

•
Investigating openness not only from IoT platform perspective, but also considering IoT middleware and frameworks.

•
To understand how much openness of IoT platforms has penetrated the field and in which domains, a mapping study of the application domains of the identified open IoT platforms would be useful.

Limitations and Threats to Validity
One of the main limitations related to openness is our search string that was focused on open IoT platforms as such, whereas we did not investigate middleware or framework in the context of our study, from which we might miss other relevant data. Other limitations for example can be related to carrying a deeper investigation on how the identified open IoT platforms were used by studying their implementation and additional characteristics as well.
Misunderstandings among the researchers involved in the review process related to search and methods could cause some biased results. For this, the five involved researchers discussed the reliability of this study in its very early stage, at design phase, with the aim to mitigate the bias. In particular, the threat was mitigated through the discussion and refinement of our review protocol before the start of the review process to ensure unbiased results.
Additionally, during the review process we identified several papers that did not provide enough information for us to suitably record the data. Therefore, the researchers met several times and discussed to disambiguate case by case and recorded the data.
Finally, for our study, we limited our search scope to well-known publishers, and that consequently may have led to miss some studies published in other venues. Therefore, to sum up, we do not claim that we collected all existing studies in the literature, but tried to include as many of them as possible according to a systematic method rigorously designed and executed.

Conclusions
In this paper, we report the results from our systematic mapping study with the aim to shed some light on what makes an open IoT platform. Overall, we observe the rapid growth of the interest in openness in IoT area.
The goal of our study was to characterize and understand the concept of openness with respect to IoT platforms. In this paper, we provide insights related to this goal. One of the main outcomes shows that in total 46