A reconfigurable smart interface based on IEEE 1451 and field programmable gate array for multiple Internet of Things devices

Abstract

The Internet of Things is becoming increasingly important in traffic, medical treatment, and other industry fields. With the development of the Internet of Things technology, lots of new “things” need to be accessed to the Internet of Things. Currently, Internet of Things applications adopt multiple methods to access the heterogeneous devices. How to provide unified access means for those “things” is a fundamental issue. To solve this problem, a new method is proposed in this article to design a reconfigurable smart interface for multiple Internet of Things devices. The IEEE 1451 standard is adopted for this design, and it comprehensively specifies the smart transducer design and relevant interface protocol to implement the intelligent acquisition for common sensors and actuators. Field programmable gate array is adopted for the implementation of this design to reduce consumption of resources and enable the reconfiguration of the whole system. Performance of the proposed system is evaluated, and good performance is achieved in practical application for office environment monitoring.

Keywords

Internet of Things IEEE 1451 field programmable gate array sensor actuator

Introduction

The Internet of Things (IoT) was first proposed to study radio frequency identification (RFID) by Ashton, Professor of the MIT Auto-ID Center in 1999. With the technological development, the concept is constantly updated. The well-established concept was proposed by the International Telecommunication Union on the ITU Internet Report, which was given as two-dimensional code reading equipment, RFID devices, infrared sensors, global positioning system (GPS), and laser scanners, and other information sensing device, according to the agreed protocol, connect to any object under the Internet for information exchange and communication, in order to achieve intelligent identification, positioning, tracking, monitoring, and management.^1,2

IoT is a major drive to support service composition with various applications.³ The architecture of IoT is illustrated in Figure 1. It consists of three layers: perception layer, network layer, and application layer. For the perception layer, various sensors, actuators, RFID tags, and other “things” are connected to the IoT with specific interfaces.⁴ Network layer is responsible to establish the communication between “things” and humans. Currently, Ethernet and wireless local area networks (WLAN) are widely used in different application environments of IoT, and some new communication technologies such as narrow band Internet of Things (NB-IoT) are becoming more and more popular. For application layer, various applications and business functions are realized for different purposes, such as intelligent transportation, green agriculture, and wise medical and smart home.

Figure 1.

Architecture of IoT.

Compared with the Internet which has realized the communication between computers and smart devices, IoT mainly enables the “things” to talk to each other. Those “things” work as the antenna of the IoT huge system and form the foundation of the various intelligent applications.⁵ How to realize the unified access to the IoT for various “things” is a fundamental and key issue.

With the rapid development of IoT technology, a large number of devices and equipment join the different application areas of IoT: intelligent transportation, green agriculture, wise medical, smart home, and so on. Among these devices, different interfaces are adopted between each other. As shown in Figure 2, the universal asynchronous receiver transmitter (UART), general purpose input output (GPIO), and other point-to-point interfaces are usually adopted by sensors and actuators. The controller area network (CAN), inter-integrated circuit (IIC), universal serial bus (USB), and other bus interfaces are the common interfaces of on-board units (OBU), real-time clock (RTC), and hard disk. ZigBee, Ethernet, and other kinds of net interfaces are usually used to connect wireless sensor nodes and digital cameras. According to the transmission rate, these connected devices are classified into low-speed and high-speed equipment. Typically, kinds of sensors, actuators, and RTC belong to the low-speed equipment, while hard disk and camera belong to the high-speed equipment.

Figure 2.

Devices and interfaces in IoT.

To address the heterogeneity problem of device interfaces, there are a lot of systems and interface equipment available on the market.^6–8 However, most of them work in a specialized environment and access limited number of devices with specialized interfaces. Furthermore, the systems or interface equipment could not be reconfigured or reused for other applications, which result in a serious waste of resources. To deal with this problem and provide a unified interface, the Institute of Electrical and Electronic Engineers (IEEE) has launched IEEE 1451 Smart Transducer Interface Standards protocol. This protocol defines a series of specifications from sensor and actuator interface definition to data acquisition, and it not only allows for the development of smart sensors and actuators but also leads to uniform industrial standards.⁹ Kumar and Hancke¹⁰ have presented a low-cost and energy-efficient prototype of a smart comfort sensing (SCS) system–based IEEE 1451 for the real-time monitoring of thermal and air quality comforts in situ. Song and Lee¹¹ have proposed a smart transducer web services (STWS) prototype system based on IEEE 1451, and standardized way for sensor applications to access and interoperate with IEEE 1451 smart transducers was discussed in detail. However, the devices with this protocol are still not widely deployed in real IoT environment.¹² For these existing works, most of them could only access limited types of sensors and actuators for specific domains. The main reason lies in the high resource cost and complexity for adopting the protocol. Typically, it needs to deploy two physical processors to handle the whole system, while the present system usually only takes one. In addition, the protocol focuses on those low-speed devices in IoT such as sensors, actuators, and transducers, while ignoring other high-speed devices or equipment.

To solve the above problem, field programmable gate array (FPGA) seems to be a good solution. First, compared with the micro control unit (MCU), FPGA can be configured to be multi-core processors and deployed to process different modules in the whole system. Besides, FPGA can support various low-speed and high-speed interfaces through custom-designed intellectual property (IP) core. With the characteristics of re-programmability, the system implemented by FPGA can be reused and extended for other applications.

By focusing on these issues, this article designs and implements a reconfigurable smart interface for multiple IoT devices. This design adopts FPGA to implement the whole system with re-programmability. With IEEE 1451 standard, the design can support various transducers for data acquisition and control. By taking full advantage of IP core, this design can also support other devices in IoT. With this design, the system could access various kinds of devices such as sensors, actuators, and other high-speed devices with flexibility and expansibility, and the hardware system including multi-core processors and various IP cores could be implemented in a single chip with low power consumption.

The rest of this article is organized as follows. The analysis of IEEE 1451 and FPGA is presented in section “Analysis of IEEE 1451 and FPGA.” The overall architecture of this design is proposed in section “Architecture overview,” and the detailed implementation of hardware and software is described in section “Implementation.” Typical application of “smart office” is discussed in section “Application in office environment monitoring.” Finally, we conclude our work in section “Conclusion.”

Analysis of IEEE 1451 and FPGA

In this section, the key technologies applied in the proposed design are analyzed and summarized in detail.

IEEE 1451 standard

To solve the problem that the current sensor bus interfaces are not compatible with each other, the IEEE launched the IEEE 1451 standard to provide unified sensor interfaces. The family of this standard defines a set of common communication interfaces to connect smart transducers to microprocessor-based systems, instruments, and networks in a network-independent environment. The main objectives of this standard are as follows:

To enable plug and play at the transducer (sensor or actuator) level by providing a common communication interface for transducers;

To enable and simplify the creation of networked smart transducers;

To facilitate the support of multiple networks.

The IEEE 1451 standard divides the parts of a system into two general categories of devices: the network capable application processor (NCAP) and the transducer interface module (TIM), which are connected by a transducer-independent interface (TII). NCAP, which works as a network node, performs data processing and network communication functions, whereas TIM consists of a number of sensors, actuators, and signal conditioning units. The TII defines a communication medium and a protocol for transferring the commands and sensor information between NCAP and TIM. As shown in Figure 3, the IEEE 1451 standard defines a set of protocols for wired and wireless distributed applications. The IEEE 1451.0 is the overview of the entire family of standard and defines a common set of commands, an electronic data sheet format, and communication protocols. IEEE 1451.1 defines the behavior of the NCAP using object-oriented model and stipulates some general modules, communication protocol, and transducer electronic data sheet (TEDS). By defining the smart transducer software interface specification between different networks, the IEEE 1451.1 can enhance the interoperability among the IEEE 1451 family of standards. The different interfaces between NCAP and TIM are defined by the IEEE 1451.2 (point to point interface), IEEE 1451.3 (multi-point bus interface), IEEE 1451.4 (mixed interface), IEEE 1451.5 (wireless interface), IEEE 1451.6 (CAN open interface), and IEEE 1451.7 (RFID interface). In practice, a variety of communication technologies could be used as the specific interface. Typically, the point-to-point interface of IEEE 1451.2 could be made with TII, UART, and USB, and the Wi-Fi, Bluetooth, and ZigBee could realize the wireless interface for IEEE 1451.5.

Figure 3.

IEEE 1451 family of standards.

The IEEE 1451 standard defines a complete set of specifications for sensors, actuators, and transducers in IoT, but the devices with this protocol still have no attractions for customers on the market. The main reason is the high resource cost and complexity for adopting the protocol. Normally, it needs two physical processors for NCAP module and TIM module, as well as the 10-line TII interface is also difficult to be implemented.¹³ With the continuous development of IoT applications, the IEEE 1451 is no longer suitable to handle the novel high-speed devices, such as digital camera and USB devices. Taking all the above factors into consideration, a unified smart interface for multiple IoT devices is in strong demand.

FPGA

FPGA is the latest programmable product developing from programmable array logic (PAL), generic array logic (GAL), and complex programmable logic device (CPLD).¹⁴ It is implemented as semi-custom circuits in a field of application-specific integrated circuit (ASIC). As shown in Figure 4, it consists of input–output block (IOB), configurable logic block (CLB), block random access memory (BRAM), digital clock management (DCM), embedded function unit, embedded specialized core, and rich routing resources. Through FPGA, various complicated hardware systems with power computing performance can be implemented just in single chip which can also be reconfigurable.

Figure 4.

Internal structure of FPGA chip.

Compared with CPLD which is implemented by combinational circuit,¹⁵ FPGA is composed of the lookup table (LUT). This leads to an essential difference between them. For example, FPGA could integrate from hundreds of thousands to millions of logical gates in a single chip, while CPLD could only reach tens of thousands. Also, the FPGA could be reconfigurable much more times than CPLD with Flash or electrically erasable programmable read-only memory (EEPROM). In terms of power utilization, the power consumption of CPLD is typically higher than FPGA due to the technical process.

Compared with traditional advanced RISC machine (ARM), MCU, and digital signal processor (DSP),^16,17 FPGA can directly implement double or more cores on single chip with limited resources for implementation of IEEE 1451. Meanwhile, IP cores can be designed to implement all kinds of functional units and interfaces. Specifically, the soft core could be used to handle TIM module, the embedded hardcore could be used to handle the NCAP module, and the TEDS could be stored in BRAM. Based on the above characteristics, FPGA comes to an efficient way to implement the IEEE 1451 standard.

Architecture overview

In this section, a reconfigurable smart interface device is designed for data acquisition, processing, storage, and transmission. The interface device is able to access various low-speed devices such as sensors and actuators, as well as high-speed devices such as camera, and hard disk. It can be widely used in different areas of the IoT environment for real-time monitoring, data acquisition, and device control.

On a single FPGA chip, all kinds of IP cores are designed to implement a set of sensors and actuator interfaces according to the IEEE 1451 standard. The interface device can automatically discover, gather, and control the connected sensors or actuators. For this, multichannel analog signal input interfaces, digital signal output interfaces, and digital signal duplex interfaces were designed and implemented. Besides, for those high-speed devices, the interface device adopts both IP cores and embedded hardware units as the interfaces to access them.

For the wired and wireless communication, the network module is designed and implemented. At present, the device has supported both Wi-Fi and 3/4G modules. In the future, more novel communication modules equipment will be continuously added to the support list. According to the different application requirements, the interface device can adopt different transmission modules to access to the Internet.

In terms of controllers, with the abundant resources of FPGA, the design adopts soft core to implement the address logic module and takes the embedded hardcore as the main controller. The logic address module is responsible for data acquisition and control for sensors, actuators, and transducers. It can work in parallel and low-power mode, which greatly reduces the resource occupancy of the whole system. The main controller focuses on high-speed devices’ access and network communication. With this design, the address logic module can greatly reduce the workload of data acquisition for main controller, which makes the whole system more efficient and low power.

In this design, the interface device collects analog and digital signals from kinds of sensors as well as transmits analog and digital signals to actuators. For this, the analog-to-digital (ADC) converter and digital-to-analog (DAC) converter are implemented for signal conversion between digital and analog. All the data collected by smart transducer interface module (STIM) will be transmitted to the NCAP module via TII and further published to the user terminals. Figure 5 shows the architecture of the smart interface device. TEDS and TII are implemented according to the standard of IEEE 1451, which will be illustrated in the following sections.

Figure 5.

Architecture of the smart interface.

Implementation

This design adopts Zynq-7000 as the implementation platform. It is based on the Xilinx all programmable system on a chip (AP SoC) architecture and integrates a feature-rich dual-core ARM Cortex-A9 MPCore based processing system (PS) and Xilinx programmable logic (PL) in a single device. The ARM Cortex-A9 MPCore is the heart of the PS which also includes on-chip memory, external memory interfaces, and a rich set of I/O peripherals. Figure 6 illustrates the functional blocks of the Zynq-7000 AP SoC.¹⁸

Figure 6.

Zynq-7000 AP SoC overview.

STIM module

STIM module mainly realizes the access of various sensors, actuators, and transducers. It communicates with NCAP module through TII. Different types of TEDS are designed and implemented in this module. The entire module is implemented on the PL part.

In the hardware design of STIM, according to the IEEE 1451.2 standard, FPGA implements the following modules: analog signal interface, digital signal interface, control module, memory module, and transmission module. The detailed hardware architecture of STIM is shown in Figure 7:

For analog signal interface, a 12-bit ADC is adopted in this design which could support up to 17 external analog input channels. Sensors with analog signal output can access to the system with this interface.

For digital signal interface, this STIM adopts both self-designed and custom IP cores to implement types of digital signal interfaces, such as UART, GPIO, and IIC. Digital sensors and actuators can access to the system with them.

In the transmission module, the link block is designed for communication with NCAP through TII. The detailed design will be illustrated in the following section.

The memory module is implemented by BRAM which is generated by FPGA resources. It differs from common RAM and can be resized according to demands. In this design, we take 64-kB BRAM for the STIM module.

Finally, the STIM adopts soft IP core as the processing core in the control module, and it is completely generated by FPGA resources with low power and high performance. The processing core communicates with the above interfaces and transmission module through the advanced extensible interface (AXI) bus and accesses the memory module with the local memory bus (LMB).

Figure 7.

Hardware architecture of STIM.

For the functions of software, according to the IEEE 1451.2 standard, the STIM module should implement the following functions:

Addressing;

Interface data transport;

Transducer data;

Meta-TEDS and Channel TEDS;

Status and control.

The STIM adopts the stand-alone system to handle the whole module, and the software workflow is shown in Figure 8. After powered on, the system begins to initialize and then enters the stage of waiting for NCAP request. When detecting the NCAP request signal, the STIM module determines the request type according to the address layout which is shown in Figure 8. For sensor data request, the module addresses it to the specific sensor, executes data read operation, and transmits the result to NCAP. For TEDS data request, the module addresses it to the specific TEDS and transmits the table to the NCAP. For actuator control request, the module addresses it to the specific actuator, executes control operation, and feeds back the result to NCAP. Furthermore, the self-test function for STIM is implemented to check the entire module status, and the results will be fed back to NCAP. The software workflow of STIM is given in Figure 9.

Figure 8.

Address layout.

Figure 9.

Software workflow of STIM.

NCAP module

NCAP module mainly implements the access of various high-speed devices and the communication with network. And it communicates with STIM module through TII. The entire module is implemented as the PS part.

In hardware design, the NCAP mainly implements the transmission module, control module, memory module, and communication module according to the IEEE 1451.1 standard. Besides, we design and implement the high-speed interface to support USB devices and Ethernet devices, which realizes the access of non-IEEE 1451 objects. The detailed architecture of STIM is shown in Figure 10.

Figure 10.

Hardware architecture of NCAP.

The NCAP adopts ARM Cortex-A9 MPCore as the control module, which could handle highly complex task with high performance, reliability, and stability. Considering the rich I/O peripherals on the chip, the NCAP directly adopts the USB, Ethernet, and other interfaces to implement the high-speed interfaces. Furthermore, with connection with Wi-Fi and 4G module, the NCAP can access the network through wired or wireless connection.

By integrating IEEE 1451.1 standard and our extension design, the NCAP module mainly implements the following software functions:

Data management: data acquisition, transmission, and storage;

Control management: actuators and other device control;

Service publication: offer web access and subscription service.

To implement the above complex functions, the NCAP needs a high-performance and stable operating system. Therefore, the PetaLinux operating system becomes a good choice for this module, which could provide various drivers for various devices and abundant libraries for application development. Based on the operating system, the control agent is designed for device control management, and the data agent is designed for data acquisition, transmission, and storage. For service publication, this NCAP adopts both web access service mode and subscription service mode. The former allows users to directly access the web pages with visual representations of the data, and the latter could push the subscription information to users timely and accurately. The architecture of NCAP module and typical application scenario is shown in Figure 11.

Figure 11.

Software architecture of NCAP.

TII implementation

TII is the interface between the STIM and NCAP, and the protocols, timing, and electrical specifications are defined in IEEE1451.2 standard. The 10-line design could support data transmission, power, triggering, and interrupt. But in practice, the main function of this interface is only to implement the data transmission between NCAP and STIM. Instead of a complex 10-line physical structure, most researchers adopt a more sample design for TII in practice. For example, both the USB and UART are common choices.¹⁵

In this design, the UART is adopted as the interface between NCAP and STIM. Compared with other interface such as USB, the simple 2-wires UART can support bidirectional data transmission more efficiently and effectively. With this simplified design, the system could work normally while reducing unnecessary resource consumption.

TEDS design

According to IEEE 1451.2 standard, a group of TEDS are defined, which could make the sensors and actuators have the ability of “plug and play” and self-calibration. Among them, the Meta-TEDS and Channel TEDS are mandatory.¹⁹ Therefore, a Meta-TEDS is designed for the STIM module, and multiple Channel TEDS are designed for each sensor and actuator connected to the interface device.

The TEDS contains fields that fully describe the type, operation, and attributes of the transducers, which is stored as a data sheet in BRAM. Taking the temperature Channel TEDS as an example, it contains the channel type, physical units, lower/upper range limit, and so on. Part of the information is shown in Table 1. The meta-TEDS length specifies 96 bytes in the Channel TEDS data block excluding this field, and the value 1 of calibration key indicates that fixed calibration information is provided. The value 0 of channel type key indicates that the channel transducer type is sensor, and its measurement unit is kelvin according to the value of physical units. Also, the measurement range is limited from 273 to 323 according to the lower and upper range limit. Once requested from NCAP, the data sheet will be packed and transmitted via TII.

Table 1.

Part of Channel TEDS for temperature sensor.

Field no.	Description	Type	Length	Value
1	Meta-TEDS length	U32L	4	96
2	Calibration key	U8E	1	1
8	Channel type key	U8E	1	0
9	Physical units	UNITS	10	0, 128, 128, 128, 128, 128, 128, 130, 128, 128
10	Lower range limit	F32	4	273
11	Upper range limit	F32	4	323

TEDS: transducer electronic data sheet.

Application in office environment monitoring

With the improvement of human living standards, the “smart office” has become a new thing which combines people’s daily work with IoT technologies.²⁰ Compared with the traditional office environment, the “smart office” could provide a more secure, comfortable, and efficient work environment through a serious of high-tech facilities and technologies.

At present, the similar “smart office” systems on the market have numerous problems in practical application. First, most of them only support a small number of traditional sensors and could not support digital camera, novel transducer, and other data acquisition devices, which makes the office environment monitoring incomplete and inaccurate. Besides, due to the absence of standard for data acquisition and processing, the systems are not compatible and interoperable with each other. To solve above problems, we design and implement a smart office environment monitoring system based on the proposed smart interface architecture, and it has the following features:

Taking full advantage of the smart interface architecture, the system supports temperature, humidity, light intensity, and air quality information acquisition as well as video surveillance. With the cooperation of hard disk and 4G module, the system implements the functions of data storage and transmission.

Based on IEEE 1451 standard, the system supports various transducers within specification for data acquisition.

With the help of FPGA and SoC embedded development technology, the kernel module of the system is implemented on a single chip, which greatly reduces the hardware resources and power consumption.

The application scenario of the “smart office” is shown in Figure 12. The office is deployed with all kinds of sensors, including light intensity sensor, temperature sensor, humidity sensor, infrared sensor, PM2.5 sensor, and hazardous gas sensor for environmental information acquisition. In addition, a high-resolution digital camera is also deployed to capture video information. Finally, all the above devices are connected to the smart interface device of the “smart office” through specialized interfaces, and users can access all the information through web browsers.

Figure 12.

Application scenario of the smart office.

Software and hardware design

Hardware design

The hardware system is based on the proposed smart interface, and it can well meet all the requirements of office environment monitoring. In this application, the Xilinx ZC702 evaluation kit is adopted to implement the hardware system.

First, we build the SoC system on XC7Z020 chip based on our proposed design. As shown in Figure 13, the SoC system contains two processors: ARM Cortex-A9 and Micro Blaze, which communicate through UART interface (ARM UART to UART_1 IP core). Meanwhile, the IIC IP core, XADC IP core, MDM IP core, BRAM IP core, RESET IP core, and two GPIO IP cores are added to the SoC system, and all of them are connected to the Micro Blaze through AXI bus.

Figure 13.

SoC system design.

Second, all kinds of devices are connected to the board with specified interfaces. All the devices involved in this application with the interfaces are shown in Table 2.

Table 2.

Specific devices with interfaces.

Device	Type	Interface
Temperature and humidity sensor	DTH 11	GPIO_1
Light intensity sensor	GY-30	IIC
Infrared sensor	HC-SR501	GPIO_2
PM2.5 sensor	GP2Y1050AU0F	XADC
Hazardous gas sensor	MQ135	XADC
Digital camera	DS-2CD2512F-IS	Ethernet
4G module	ZTE ME3760	USB
Hard disk	WD 10JUCT	USB

Finally, a prototype system has been developed and deployed in the office for real-time environment monitoring (Figure 14). All kinds of environmental information in the office are continuously collected, stored, and transmitted.

Figure 14.

Prototype system.

Software design

Software design of the office environment monitoring system mainly includes two parts: the data acquisition and data distribution. In the stage of data acquisition, we have designed integrated software system for the STIM module and the NCAP module. It contains complete functions of real-time data acquisition and control for sensors and other devices. Also, the communication with standard data format and protocols between two modules are considered. In the stage of data distribution, a web server based on PetaLinux is established on STIM module for user access. It is based on common gateway interface (CGI) and hypertext transfer protocol (HTTP), which could realize the visualization presentation of collecting data. With this, user can intuitively view the detailed environmental information as shown in Figure 15.

Figure 15.

Web interface.

Performance evaluation

As an actual application, the smart office can perform the real-time and comprehensive monitoring for office environment, which includes temperature, light intensity, humidity, air quality, and video information. All the data could be stored locally and presented to the users by visual interfaces.

Taking all advantage of the proposed smart interface architecture, the system has good compatibility and expansibility for different types of sensors, actuators, and other devices in IoT. For specific user requirements, the system could be reused and expanded for other application environment.

By adopting FPGA and SoC technologies, the system has powerful data processing capability while consuming less hardware resources. Figure 16 shows the resource utilization and power consumption of this design. The left chart shows resource utilization of the SoC system. Among them, this design only takes 7% LUT resources and 20% BRAM resources of the XC7Z020 chip. The right chart shows the power estimation of the SoC system. The total power consumption is about 1.8 W including 0.16-W device static power and 1.638-W dynamic running power. Compared with the total available power of 5 W, this design only takes about 36% of the available chip power. With this, the entire system runs with efficiency and effectiveness.

Figure 16.

Power and resource utilization of the SoC.

Conclusion

This article proposes a reconfigurable smart interface for multiple IoT devices. It was designed based on IEEE 1451 standard and FPGA technology. The proposed architecture could access various sensors and actuators as well as novel high-speed devices, and it is suitable for various kinds of applications in IoT fields. Taking full use of FPGA and SoC technologies, the system has powerful processing capability, good compatibility, and expansibility while consuming less hardware resources and power. By taking the application of smart office as an example, we verified that the system has good performance and reliability in practical application.

Note that many interesting directions are still remaining for further research. For example, considering that the system only realized wired connection for a part of IoT devices, how to achieve the wireless access for other devices is an important issue. Our future work will focus on this aspect.

Footnotes

Academic Editor: Jayavardhana Gubbi

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

This research was supported by the National Natural Science Foundation of China (No. 61502018 2016.1-2018.12) and Beijing innovation platform of Science and technology.

References

Whitmore

Agarwal

LD.

The internet of things—a survey of topics and trends. Inform Syst Front 2015; 17(2): 261–274.

Zhao

The internet of things: a survey. Inform Syst Front 2015; 17(2): 243–259.

Viriyasitavat

A novel architecture for requirement-oriented participation decision in service workflows. IEEE T Ind Inform 2014; 10(2): 1478–1485.

Huang

Chen

Cheng

A stochastic approach of dependency evaluation for IoT devices. Chinese J Electron 2016; 25(2): 209–214.

Razzaque

Milojevic-Jevric

Palade

. Middleware for internet of things: a survey. IEEE IoT J 2016; 3(1): 70–95.

Fernández-Caramés

TM.

An intelligent power outlet system for the smart home of the internet of things. Int J Distrib Sens N 2015; 11(11): 1–11.

Fadlullah

Fouda

Kato

. Toward intelligent machine-to-machine communications in smart grid. IEEE Commun Mag 2011; 49(4): 60–65.

Kumar

Singh

Sud

SK.

Energy efficient and low-cost indoor environment monitoring system based on the IEEE 1451 standard. IEEE Sens J 2011; 11(10): 2598–2610.

IEEE 1451 smart transducer interface standards, http://www.nist.gov/el/isd/ieee/IEEE1451.cfm (2009, accessed 10 September 2016).

10.

Kumar

Hancke

GP.

An energy-efficient smart comfort sensing system based on the IEEE 1451 standard for green buildings. IEEE Sens J 2014; 14(12): 4245–4252.

11.

Song

Lee

KB.

STWS: a unified web service for IEEE 1451 smart transducers. IEEE T Instrum Meas 2008; 57(8): 1749–1756.

12.

Kumar

Srivastava

Singh

. Current status of the IEEE 1451 standard-based sensor applications. IEEE Sens J 2015; 15(5): 2505–2513.

13.

IEEE P1451.2, http://grouper.ieee.org/groups/1451/2 (2003, accessed 10 May 2015).

14.

FPGA, http://en.wikipedia.org/wiki/Field-programmable_gate_array (2011, accessed 10 May 2015).

15.

Chi

Yan

Zhang

. A reconfigurable smart sensor interface for industrial WSN in IoT environment. IEEE T Ind Inform 2014; 10(2): 1417–1425.

16.

Wei

Chen

. An intelligent optical dissolved oxygen measurement method based on a fluorescent quenching mechanism. Sensors 2015; 15(12): 30913–30926.

17.

Mattoli

Mondini

Mazzolai

. A universal intelligent system-on-chip based sensor interface. Sensors 2010; 10(8): 7716–7747.

18.

Zynq-7000 all programmable SoC: technical reference manual (Ug585), http://china.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf (2015, accessed 10 December 2016).

19.

Lee

Gatton

TM.

Wireless health data exchange for home healthcare monitoring systems. Sensors 2010; 10(4): 3243–3260.

20.

Ryu

Kim

Yun

Integrated semantics service platform for the internet of things: a case study of a smart office. Sensors 2015; 15(1): 2137–2160.