1 Introduction

The recent arrival and proliferation of the Internet of things (IoT) has led to the development of infrastructure for capturing and storing data, ranging from small smart devices to smart cities (Mois et al. 2017). In an IoT infrastructure, data collected from a large set of sensors is processed, analyzed, and often fed back to actuators or smart devices to control nearby environments (Chindenga et al. 2016; Suryani et al. 2017; Vanus et al. 2018). The deployment of IoT devices with a richer variety of sensors and actuators can provide fine-grained monitoring and control larger regions with various usage contexts.

IoT is composed of embedded devices equipped with low power sensors and actuators that are connected in wireless networking environments (Yang et al. 2016; Uddin et al. 2018). A large variety of IoT devices and their peripherals are available in consumer markets, and compatible device drivers should be developed for each peripheral (Toosi et al. 2018). Such device drivers, however, should be customized for sensing and actuating nearby environments, and overhead is often involved due to human intervention for customizing and maintaining device software (Tucci et al. 2017). For example, devices deployed in a home may initially be configured to monitor light intensity. After some time, a temperature sensor is needed in the home and a light sensor is no longer required. In such a case, one cannot remove the light sensor and directly attach a temperature sensor. Instead, a new device driver is required to operate the temperature sensor and to integrate the temperature sensor and its peripherals. This implies that IoT application deployers must work on customizing appropriate device drivers whenever new service demands arrive or service demands change, and the complexity of IoT development and deployment will increase given the variety of IoT devices and their peripherals that should be customized. Whenever it is necessary to reconfigure a variety of IoT devices and their peripherals, a massive amount of programming and maintenance work is required to prepare and connect the IoT devices peripherals.

This paper proposes a generic platform that enables PnP integration for various IoT sensors and actuators. The main advantage of PnP architecture is that it allows for the addition and removal of IoT peripherals independent of sensors and actuator device types without re-customizing or re-installing all of the local device drivers. In particular, all local device peripherals are classified into digital/analog types and sensor/actuator types, and they require their own device configuration rules and input/output (I/O) behaviors corresponding to their device specifications. For example, digital sensors and analog sensors gather and process data in different ways and generate data in different formats. Replacing device peripherals, therefore, requires new device configurations and different I/O function calls according to their specifications.

The goal of this study is to provide PnP IoT devices with over-the-air deployable, scalable, and robust drivers. To this end, we employ IoT ontologies and web semantics as well as generic programming techniques in order to configure and control IoT devices requiring minimum human involvement. Ontology is a formal and explicit specification of knowledge in the domain of interest (Guarino 1998). Ontology defines shared knowledge in terms of classes, relationships, and axioms (Islam and Islam 2016). Ontology addresses the existence of entities and the relationships among entities, which allows for the drawing of inferences about how they interact with other distinct entities in the real world (Vijayarajan et al. 2016). In the proposed platform, IoT device characteristics, including I/O functions and configuration rules, are defined using our custom-built IoT ontologies and written in resource description framework (RDF) format (Hjelm 2001) such that appropriate device function calls and behaviors are inferred through SPARQL (Prud’hommeaux and Seaborne 2008) queries. Our generic platform then passes function-call name and configuration rules corresponding to the newly added peripheral device’s specification through a wireless network/serial port.

We implement device drivers using generic programming techniques accepting most of the function calls available in the Arduino (Severance 2014) platform, which we focused on for the IoT target application. Using generic implementation and semantic information provided by a semantic inference engine, IoT devices can select the appropriate device function calls for correct device behavior without reinstalling device drivers or changing IoT modules. The raw data gathered from sensors is transmitted to a local server and converted using a pre-defined formula to create a user-understandable sensing value that is later visualized on the dashboard in the central server. In this platform, therefore, most of the programming work that is required for normal device configuration is unnecessary, and as a result, this platform enables PnP device experiences responding to dynamic IoT service demands.

The remainder of this paper is structured as follows: Sect. 2 reviews related works regarding semantic supports for device communication and the corresponding operations. Section 3 provides an overview of our generic IoT PnP platform. Section 4 presents our IoT ontologies and their semantic representation for IoT sensors and actuators, focusing on generic device operations. Section 5 describes how ontologies and semantics are integrated into the generic architecture and how inferring device characteristics enables appropriate function calls to run a newly added device correctly without reinstalling drivers or changing the whole IoT module. Additionally, this section explores how the generic platform is implemented from the IoT device side. Finally, Sect. 6 concludes our contribution from the paper and discusses future work.

2 Related work

Semantics and ontologies have been part of IoT from the beginning and enable the automation of IoT devices (Kovacs and Csizmas 2018; Fattah and Chong 2018). The most prominent examples of IoT ontologies are the semantic sensor network ontology (Haller et al. 2017), the web of things (WOT) by Kaebisch et al. (2019), IoT-lite (Bermudez-Edo et al. 2015), smart appliances reference (SAREF) ontology (Roes et al. 2015), IoT ontology (Kotis and Katasonov 2012), and IoT-O (Seydoux et al. 2016). Internet of things vocabularies and ontologies defined from these examples can be imported from each other and are therefore able to cover most of the concepts used in IoT environments. Regarding the current approach of building a generic PnP device platform applicable to low-powered embedded devices, it is necessary to extend existing successful IoT vocabularies and therefore to facilitate low-level control of the embedded devices using I/O function calls and hardware-level configurations.

Machine-to-machine (M2M) technology has been widely studied and used in many diverse realms to enhance interoperability among large-scale heterogeneous devices and services through device abstraction and semantic support (Cackovic and Popovic 2013; Wu et al. 2011). Current IoT devices and applications have been designed and deployed independently; hence, all interacting applications must agree beforehand on a specific terminology before establishing any communications. The semantic web is often considered a key to integrating global M2M standards and various industry applications (Ayalla et al. 2017; Chellouche et al. 2013). Object vocabularies discovered and inferred from web semantics enhance interconnection between device communications. A semantic-based reasoning mechanism enables the discovery of IoT device-specific information and the determination of required actions for the device peripherals (Park et al. 2014; Charpenay et al. 2015). As a result, the management overhead on a growing number of interconnected IoT devices can be minimized as the capability of semantic inference can reduce the human intervention cost needed for IoT device management. However, M2M technology using semantics mostly focuses on device interoperability and data integration generated from heterogeneous IoT data sources. M2M technology does not address issues over generic application architecture handling heterogeneous device peripherals, which require customized software architecture responding to dynamic device specific semantics.

There are open standards to be proposed for M2M communications, such as 3GPP (Roessler 2017), OMA LWM2M (Mcllroy 2019), ETSI SmartM2M (Buonaccorsi et al. 2012), and oneM2M (Swetina 2018). Those M2M standard protocols are designed to ensure interoperable and cost-effective operations for the sensor networks and M2M environment, managing lightweight and low-power devices on a variety of networks, and hence delivering services for the combination of IoT with the description of things and the context in which they are used. They often require remote management of IoT devices and define an extensible resource and data model. Some of those standards additionally propose IoT data management mechanisms for secure data exchanges.

Firmata (Langbridge 2015) is a generic protocol for communicating with microcontrollers from software on a host computer. Firmata allows the control of IoT devices from software on the host computer using client libraries implemented on a generic communication protocol to IoT devices. Through Firmata, a software that controls devices can be written with various programming language in which a programmable interface is provided. Even though Firmata offers easy implementation of a software that controls devices, it does not support dynamic discovery and selection of available software modules that respond to dynamic device operational semantics.

PnP enables device compatibility and on-the-fly scalability and reconfigurability (Ghazanfari et al. 2018). PnP design has been widely studied, and many standards exist to achieve universal interoperability between systems (Tan et al. 2015; Androcec and Vrcek 2016). These PnP standards mostly focus on interoperable protocols and exchanging data representation. Regarding IoT peripherals that do not have enough computing capacity, existing PnP standards cannot be applied because PnP standards require enough computing capability to process the suggested protocols and manage data representation. Works from (Liu et al. 2016; Bordel et al. 2016) implemented PnP frameworks over the sensor networks called cyber-physical systems (Ribeiro and Bjorkman 2018; Serpanos 2018). Their PnP connectivity works between sensor devices and a local gateway. For each sensor device, device drivers should be implemented individually; however, those approaches are not based on the generic architecture. (Farzaneh and Knoll 2016) applied PnP ontologies to sensor networking, but they used ontologies for device operational configurations based on pre-defined device characteristics. This approach still requires device driver customizations before integrating devices into their sensor network.

As IoTs has become the part of our daily life due to their communication and computing capabilities, IoTs requires seamless interactions among different types of many cheap sensors such as medical sensors, monitoring cameras, home appliance and so on. One of notable example is IoT-based healthcare system (Gope and Hwang 2015), where sensors in healthcare systems monitors and collect the human health functions and surrounding environment. As sensors in the healthcare system handle sensitive information, strict security mechanisms are required to prevent malicious interactions with the system. To address security issues on IoT healthcase system, Gope and Hwang (2015, 2016) proposes a lightweight IoT based security platform to be used in the healthcare system. In their proposal, three components, named Body Sensor Network, Local Process Unit and BSN-care server, work together for user-authentication and secure data transmission, which has similar architectural shape with our approach where we maintain three independent corresponding components (IoT device, local server, central server). We believe Gope and Hwang’s proposal (2015, 2016) can be easily implemented into our proposed platform by separately incorporating their protocols for Body Sensor Network, Local Process Unit and BSN-care server into our IoT devices, local server and central server respectively. Therefore our PnP IoT platform can become trustworthy in hostile IoT environments.

Generic programming allows programmers to instantiate a single logic for a variety of data types and algorithms (Altenkirch and McBride 2003). There are many approaches to make solutions generic when there are many individual logics that require infrastructural knowledge in order to generate the corresponding components (Aoudia et al. 2016; Atanasov et al. 2016; Cresson and Hautreux 2016; Le Nir and Scheers 2017). However, their implementation focuses on middleware, not on device-level firmware architecture.

3 A PnP architecture for generic IoT devices

This study presents a PnP generic platform for IoT devices using ontology and the semantic web. We use the Arduino platform for IoT devices and their peripherals and Apache Jena API and SPARQL for semantic processing, which are located in a local server.

Figure 1 illustrates our semantic-based approach to build PnP architecture for generic IoT device management. The proposed architecture has three main components: IoT devices, a local server, and a central server. The descriptions of these components are as follows:

Fig. 1
figure 1

A PnP architecture for generic IoT device management

Full size image

  • Internet of things devices are either IoT sensors or actuators intended to monitor/control their nearby environments. IoT devices are composed of sensing/actuating peripherals and a network interface for communicating with a local server. Generic software drivers handling device dynamics are installed here. IoT devices accept device customization information from remote servers and configure themselves to correctly run the attached peripherals. They also send sensing data/actuating feedback to the local server in raw format.

  • The local server sends device customization information to IoT devices and converts raw data obtained from IoT devices to a user-understandable format. To generate device customization information, a local server receives device knowledge from the central server, and an inference engine inside the local server infers the appropriate configuration. The inference engine in this study uses Jena API. A Post Evaluator inside the local server translates raw data from IoT devices to a user-understandable format using an equation formula provided in the central server.

  • The central server has a dashboard, knowledge base, and device database. The dashboard displays data collected from IoT devices and triggers, creating new device information. The knowledge base stores IoT device ontologies to be used to infer device configuration information. Device DB contains the current configuration information of the devices along with their sensed dataset.

The service flow of the proposed generic platform is described as follows. When a peripheral is removed and new peripheral is attached to an IoT device, the IoT device driver needs to be re-configured for the new peripheral’s characteristics. Therefore, the device triggers a reconfiguration request and waits for device configuration information from the local server. The device reconfiguration request is then delivered to the central server through a local server connected to the IoT device. Once the trigger event handover from the local server to the central server, the local server locates the device identification (ID) from a list of directly connected IoT devices and adds it to the triggering message.

At the central server side, the local deploying manager checks a re-configuration request with the device’s ID obtained from the IoT device. Given the device ID, the central server locates the device type and all the configurable information that can be applied directly in IoT devices. The device configuration information includes the hardware connection configuration from an IoT deployer and the name of the appropriate I/O function calls with necessary additional function calls. The device configuration information is inferred based on our knowledge base stored in the central server and displayed on the dashboard. The dashboard in the central server provides available options regarding the device configuration information through an inference process such that an IoT deployer manually selects the appropriate configuration through the dashboard with respect to the designated behaviors of newly added IoT devices. Parameters regarding delay time or variable initialization needed for operating native device functions can be selected through a dashboard provided in the central server.

Once the IoT deployer finishes the selection process required for device configuration, the configuration information is sent to the local server, which is connected to the corresponding IoT device. The device configuration information is written in JavaScript Object Notation (JSON) format and composed of message ID, the device type and device parameters which is selected from our dashboard UI forms. Our dashboard maintains dynamic UI form to accept device specific parameters in runtime. So, for each new device peripherals attached, a device-specific data selection form is dynamically displayed in the dashboard.

The local server translates the information to the device dependent specific format used for customization of the generic software modules. The IoT device is implemented generic and has no device-specific information. Therefore, the local server should maintain a list of available device types which can be attachable as peripherals. As each peripheral runs on its own properties, additional device parameters which are used to define behavior mechanisms should be created at the local server and delivered to the device along with parameters selected at the dashboard. Parameters regarding device behavior are created using inference engine and knowledge based. Inference engine infers necessary function calls of generic software driver using knowledge base defined based on our IoT ontology. Inference engine in the local server creates all the necessary function calls to run newly attached peripheral devices and attach the function calls to the messages from the central server.

The local server then sends the configuration information to the corresponding IoT device. The configuration information is then composed of message ID, parameters which IoT deployer selected at the dashboard, and parameters of a list of function calls needed for operation of newly attached device peripherals. After IoT devices accept configuration information, they begin to collect data from IoT peripherals. Because sensed data in analog sensors is represented by the degree of voltage, the data should be translated to a user-understandable format employing an evaluation function provided by sensor specification. For example, if the sensed value obtained from an analog temperature sensor was 3.73, this value should be translated into the user-understandable value of 21.3 °C. The local server maintains the sensor device’s post-evaluation functions from the knowledge base and converts raw data obtained from IoT devices to a user-understandable ranged value. The local server then sends the data to the central server to be displayed on the dashboard and to be stored in the device DB.

4 Ontologies and semantic web representation for PnP generic device management

This section describes our ontologies that enable PnP device operations over our generic platform (Fig. 2). Based on the present ontology, IoT devices are identified as sensor/actuator and analog/digital. The device also has several characteristics regarding device behavior and architecture. In the present ontology, devices have four properties, namely hasBehavior, handleEvent, hasCommunication and handleException. hasBehavior represents the basic behavior of IoT devices. handleEvent describes how a device would manage event notification. hasCommunication describes whether a device uses FIFO buffers or memory for storing stream data. The data fetched from sensors is in raw format and must be transformed in an understandable way. Through ExceptionHandling, an IoT deployer can designate the way of handling exceptions. We provide three exception-handling methods: suspend, fault, and watchdog. In case a device software is constructed with multiple patterns, an IoT deployer can select a specific pattern to efficiently conduct tasks.

Fig. 2
figure 2

Ontologies used for implementing our generic PnP platform

Full size image

From our experiment, some device software can be constructed with object-oriented language, such as C++, and designing architecture with patterns are more efficient in supporting various device operations. hasBehavior defines common device behaviors. We have identified 17 common device behaviors, which are integrated into device driver software. Device behaviors include several native steps, such as data preparation and I/O system calls. Figure 3 describes an ontology of behavior Debounce. Behavior Debounce is composed of parameters of initializing database, database input/output, and other necessary parameters required for correct execution.

Fig. 3
figure 3

Ontologies for Debouncing behavior

Full size image

Figure 4 outlines our semantic representation of BlinkWithoutDelay behavior in RDF format, which needs several parameters for variable initialization and loop inputs. Figure 4 describes the parameters required for the device drivers. The behavior is stored in the knowledge base located in the central server. The central server infers the needed parameters from the knowledge base and displays them on the dashboard such that IoT deployers select the appropriate values for the device parameters.

Fig. 4
figure 4

Representing BlinkWithoutDelay behavior in RDF Format. This file is stored in the knowledge base of the central server and used to infer necessary parameters for a newly replaced sensor peripheral

Full size image

5 Implementation

We have implemented our generic platform on a customized Linux server with Jena API for the central server, Raspberry Pi for the local server, and the Arduino platform as an embedded IoT device. We connect the Arduino IoT platform to a Rasberry Pi local server directly, and peripherals of sensors and actuators are attached to the Arduino IoT platform.

Figure 5 illustrates a dashboard hosted in the central server. Through a dashboard, an IoT deploying engineer catches newly replaced sensor information and available configuration options. The central server infers all the available configuration options through Jena API with SPARQL queries. To update new peripheral device information, a user should enter the device ID pre-set before installation, the operation type (either sensor or actuator), the sensing type (either analog or digital), and the sensor’s name. The information received from the central server is then passed from the central server to a local server. Once the deploying engineer completes the device configuration process, he will see the data stream collected from the IoT devices.

Fig. 5
figure 5

Dashboard in central server

Full size image

The central server uses SPARQL to infer the device configuration and operational information from device ontologies and device information written in RDF. Figure 6 is a SPARQL query example corresponding to the IoT deployer’s input. The IoT deployer obtains device information, such as the operationType “sensor” and the sensingType “Analog” for the device ID “02a1ae01.” Using the information provided from SPARQL queries, the local server infers the desired behaviors, the sensor conversion equation, the desired delay value, and the pin configuration from knowledge written in RDF. An IoT deployer then provides device configuration values that will complete the device replacement process.

Fig. 6
figure 6

A SPARQL query sample to infer device configuration options

Full size image

Figure 7 describes a message sent to the local server. The outputs shown in Fig. 7 are written in JSON format and fed into a local server through a wireless network or serial port. The values of the JSON attribute operatingType, SensingType, and Sensors as information from device configuration information on this generic platform. These values are converted into the appropriate integer values and sent to IoT devices, especially for the Arduino device.

Fig. 7
figure 7

An example of a device configuration message from a central server to a local server

Full size image

In addition to message transfer and conversion, a local server conducts post-processing tasks, which are required for most types of sensors. Post-processing involves making the raw data obtained from the IoT device into user-understandable ranged values through the conversion formula. As each sensor requires its own the conversion formula, the dashboard enables the user to personally enter the conversion formula or retrieve the formula from the knowledge base. The conversion formula entered by the user is stored separately in the RDF format and sent to the local server.

To be generic over various types of device peripherals, we employ a generic software architecture in which device-native functions are operated selectively based on configuration information. To create generic software, we first identify characteristics of IoT device operation which most IoT sensors/actuators hold. From our research, most IoT sensors runs periodic operations with some external interrupts. So the outmost layer of generic programming structure is a loop structure in which device specific operating routines, timers and interrupt handlers are located. We adopt Façade patterns to make device operate in selective way based on external parameters delivered from the local server. We also adopt state machine pattern to compose generic programming structure. State machine holds the runtime device’ internal state and enables decisive operational behavior based on the device’s state. Our PnP platform adoptS state machine pattern and façade patterns to enable dynamic operations of generic software modules.

Toward generic implementation, we used function pointer arrays to enable the optional function selection. Attributes of Fig. 7 match the function pointer array name, and the values denote the index of a function pointer array. For example, when the inferred output includes sensor in operationType, the operationType function array is activated and function isSensor is called. When the device is detected as an analog sensor, the corresponding sensor function will be activated based on the sensor name. As Arduino’s serial communication method does not support complex communication and we found that JSON data processing consumes a considerable amount of Arduino CPU power, a local server takes on the role of JSON processing and sending value-only messages to IoT devices. The message includes the function call ID and parameter values with delimiters only. The order of values in a message is predetermined and shared between the local server and IoT devices.

We provided most of the primary sensing operations presented in the Arduino platform. Because the Arduino platform is so simple and the number of function calls is limited, enumerating Arduino system calls is not a huge task and does not take much memory space. The following are parts of the generically implemented device source code:

figure a

As a result, our generic approach covers various types of sensors/actuators supporting diverse device behavior. Table 1 shows the coverage of our generic IoT platform. Our generic driver covers most of analog sensors available in the market and supports most of the required behaviors. As for the actuator, our generic driver works on LED, step motor, and speakers as they do not need additional complex operating logic, which is required for robot arm. Our approach could not cover some digital sensors, for example, infrared rays and digital cameras, because such sensors require additional hardware modules as well as a special software library provided by the vendor.

Table 1 Sensor coverage over a single generic driver
Full size table

For analog sensors operation, parameters related to software function calls fed into IoT devices are mostly identical. Most operation except timers are identical for all the analog sensor listed in Table 1. For digital sensor, we use façade pattern inside main loop structure, in order to generate sensing value cause most digital sensors require vendor specific libraries.

For actuators, we apply digital actuators only as market does not provide analog actuators currently. The operations of actuators are more complex as the actuating operation requires its own operational logic that is not covered by periodic digital write operation. We use state machine pattern that supports decision process requires to cover non-periodical operation.

6 Conclusion

This paper proposes a generic platform supporting PnP IoT device management. To this end, we employed web semantics based on IoT ontologies in order to generate a PnP device configuration that can operate IoT devices correctly without replacing IoT modules or installing new drivers. We designed our own IoT ontology to define fine-grained software operational semantics. With façade pattern, we incorporated modulized operational semantics into generic program structure. Dynamic behavior of actuating devices is supported through state machine patterns inside our generic device software architecture. The composition rules respecting device behavior are inferred using web semantics and SPARQL queries.

In this PnP approach, sensing and actuating peripherals, such as light sensors and step motors, could be added and removed on the fly, which reduces the level of complexity of implementing and maintaining an IoT environment when IoT service demands change dynamically. Considering massive and dynamic usage patterns of devices and their peripherals, we believe our platform could save tons of efforts to maintain IoT infrastructure.

In terms of future research, the plan is to improve the platform in order to cover a broader range of sensor and actuator types. Some digital sensors require a mixed set of read/write I/O functions with complex bit operations. To cover these types of sensors, we plan to expand their semantic representation to support more complex interactions between IoT devices and their peripherals. Additionally, the present approach’s device coverage is currently limited to sensors that do not require third-party external libraries. Due to the limited memory size of IoT devices, a wide variety of external libraries cannot be preinstalled at all. In such cases, we will look for and implement dynamic linking solutions in IoT devices.