This full text paper was peer-reviewed at the direction of IEEE Instrumentation and Measurement Society prior to the acceptance and publication.
Internet-of-things infrastructure as a platform for distributed measurement applications Elisa Spanò, Stefano Di Pascoli, Giuseppe Iannaccone Polo Universitario Sistemi Logistici and Dipartimento di Ingegneria dell’Informazione University of Pisa, 56122 Pisa, Italy e-mail:
[email protected],
[email protected],
[email protected]
Abstract— The keystone of many applications associated to the vision of the Internet of Things is a distributed measurement and data acquisition system. Its design represents a major challenge, because it must enable concurrent measurement of different signals, with heterogeneous sensors and communication protocols. It must also be secure and scalable (in the sense of low marginal cost of adding new features and sensors). We propose the architecture of such a system and demonstrate two different use cases: a distributed system for electric power metering, and a wearable ECG monitoring system for multiple patients. We show that our proposed solution is flexible in terms of measured quantities, and can easily adapt to different data rates. In addition, it allows us to reach record performance in terms of energy consumption per effective number of quantization levels, as we demonstrate in the case of ECG sensors. Keywords—Internet of Things, distributed data acquisition, wireless sensor networks, wearable sensors
I.
INTRODUCTION The Internet of Things (IoT) is a scenario in which physical objects can communicate with each other and can be accessed through the Internet. At the present stage, there is no globally accepted standard for communication among objects (and new standards are still in the making), and there is no dominant player or accepted standard platform at the application level. Instead, there are several proprietary consumer solutions consisting of small sets of devices and applications (e.g. Nest thermostat [1], WeMo smart home applications [2]), or more complex business solutions consisting in sensors, data infrastructure, and control centers for industrial automation applications [3]. The availability of low-cost sensors, actuators and computing devices able to collect, elaborate, and share information over the Internet is increasing, and it is enabling the transition from traditional measurement systems to distributed data-acquisition systems [4]. Instruments and sensors connected to the Internet can be deployed and configured to perform measurements at a given rate and send data to a distributed or centralized server [5]. Collected data can then be stored, monitored, or acted upon on the basis of human decisions or algorithmic rules.
978-1-4799-6144-6/15/$31.00 ©2015 IEEE
A measurement and data acquisition infrastructure connected to the Internet is a fundamental component of any meaningful realization of the Internet of Things. In this paper, we address the following problem: Can we design an internet-of-things infrastructure that can support different and concurrent distributed measurement applications? Such infrastructure must have a challenging set of requirements: it must i) enable continuous measurement of heterogeneous quantities with ii) distributed sensors from different vendors using different protocols, iii) securely collecting and transmitting data iv) with the appropriate bandwidth to a remote server over IP. Here we therefore do not consider solutions based on industrial field-bus protocols [6] or proposed for a specific type of sensors [7]. Rather, we focus on broadening the scope and on improving the scalability of wireless and wired sensor networks, as discussed in the Related Works section, in order to address distributed measurement applications. In the following, we use two different use cases to show that an IoT infrastructure can solve the problem with several advantages and elements of novelty with respect to the state of the art. In more detail: •
We show that our architecture enables the seamless integration of wireless sensors using different communication protocols (e.g. ZigBee, WiFi, Bluetooth, etc.), and requiring different transmission data rates.
•
We show that our proposed system deals with sensor data in their native protocol format, and only interprets them in the server, where large computing power is available, therefore reducing the marginal cost of adding a new sensor protocol.
•
In addition, it enables different applications to use the same measurement infrastructure, because
This work was supported in part by the Italian Ministry of Economic Development through the Cleverhome Grant, by Quantavis s.r.l, by the Tuscany Region under the SED POR-FSE, and by the Italian MIUR and the European Commission through the ENIAC JU grants ERG (contract n. 270722-2) and E2SG (contract n. 296131).
measurement and data collection are functionally separated from data storage and utilization. •
We show that our data acquisition system supports the concurrent operation of multiple sensors, with significant savings in terms of infrastructure cost, and very low marginal cost of adding a sensor to the system.
Our two considered use cases have very different requirements in terms of signal characteristics and transmission data rate: •
Electric power metering in the smart grid/smart home domain, with adjustable sampling rate between 10 sample/s and close to zero.
•
Wearable electrocardiogram (ECG) monitoring in the health/fitness monitoring domain, with adjustable sampling rate (~320 samples/s).
II. SYSTEM ARCHITECTURE, COMPONENTS AND MAIN ASPECTS The architecture of our Internet-of-Things platform is illustrated in Fig. 1, and is described in detail in Ref. [8]. Here, we shall very briefly illustrate the main aspects, with special regard to the measurement and data acquisition system. The platform has three main parts: the sensor and actuator networks, the Internet-of-Things (IoT) server and the user interfaces for visualization and management.
Fig. 1. Block diagram of the Internet of Things platform supporting the inhome Smart Grid.
1. Sensor and actuator nodes (SANs) communicate in a reliable bidirectional way with the IoT server: they can use wireless protocols (e.g. ZigBee, WiFi, Bluetooth Low Energy, etc.) or wired protocols. The communication between nodes and the IoT server follows the TCP/IP client-server model, directly or through a gateway. Sensors send messages in their native format to the IoT server, where the data management unit extracts
information and enters it in a “universal” format in the sensor database. When sensors need to be configured or interrogated, the configurator unit prepares a command according to the target sensor protocol. Let us point out that both the gateway and the message dispatcher are transparent at the logical communication level between sensors and IoT server. This aspect provides a great flexibility advantage: new sensor protocols and new functionalities can be added without changing the gateway and the message dispatcher. In addition, a gateway that does not interpret data can have reduced hardware complexity. 2. The IoT server converts the raw payload from heterogeneous nodes into a “universal” format, containing object identifier, object type, measurement unit, data field, geographical position, and timestamp. Then, it makes data available to applications and users. In this way, data visualization and processing is separated from measurement and data collection, and does not need to take into account the communication protocol of the originating source. In addition, the IoT server receives data from users in order to configure and manage the SANs. The main components of the IoT server are illustrated in the cloud of Fig. 1, since they can be part of a distributed information system. The message dispatcher manages the bidirectional communication with the sensor networks, using no information on the network protocol or on the type of application. The data management unit is a collection of software modules interpreting data from sensors and storing them in a universal format in the sensor database. The configurator unit receives inputs from users or applications and translates them into protocol-specific commands to the SANs, consulting the configuration database. Finally, the secure access manager provides access to stored information and SAN configuration only to authorized users and applications, according to information contained in the user database. 3. User interfaces (web-based or application program interface) allow users and third-party software to access live and historical sensor data. The same interfaces also allow users with administration privileges to manage networks and single nodes. In a distributed measurement system, aspects related to data security and synchronization are critical and must be dealt with: • Security: the platform ensures an adequate security level both to end-to-end communications and to data access. For this reason, users need to be authenticated before they can access the platform and can only access specific sets of sensor data through HTTPS. The IoT server
supports multiple encryption technologies (AES-128, SSH). • Timing aspects: In the proposed architecture, the timing information can be imposed at different stages of the data path, from the individual sensor node to the IoT server. In order to enable the use of simple sensor nodes and gateways with limited complexity and low power requirements, and in particular to allow the sensor nodes to go into sleep mode, the implemented system sets the data time reference at the IoT server front end. The drawback of this solution is the presence of a delay in the received data, composed by two terms, the local sensor network delay tloc and the gateway-server delay, tgs. In the case of a local sensor network based on a single hop ZigBee network, tloc can be estimated in 10 ms [9] and tgs is the internet latency (seldom larger than 200 ms [10]).
current and voltage; on/off status. The power meter can turn the load on and off, and is configured and controlled through the user interface.
Fig. 2. Zigbee-IP gateway prototype
Hence this solution is accurate up to the scale of seconds, which is typically enough for most environmental, smart home, or vital data measurement applications. III. SENSOR NETWORK DEMONSTRATION Here we discuss two use cases of the measurement platform for two very different types of sensor networks, in terms of applications, signal characteristics, and data rate. Only for demonstration purposes, we have implemented both demonstrators with ZigBee sensors. However, we want to point out that the architecture allows us to add any type or wireless sensor protocol at minimum cost. Indeed, we would only need to add one software module to the data management unit (to interpret data from sensor) and one software module to the configurator unit (to send commands to the SANs).
a)
b)
• Gateway Since we are considering ZigBee devices, an IP/ZigBee gateway is required, as shown in Fig. 1. As we discussed in Section II, our architecture requires very low computing capabilities for the gateway, which has simply to relay messages from and to the IoT server. To reduce chip count, we have used a microcontroller (MCU) with an on-chip Ethernet controller, based on an ARM Cortex M4 processor with hardware encryption (Freescale Kinetis K60 MCU). Communication with the ZigBee network is provided by the Freescale MC13224 SoC, equipped with an AES128 encryption engine. The gateway prototype is shown in Fig. 2. The gateway uses the lwIP TCP/IP stack [11] and can auto configure its network interface when connected to a LAN equipped with a DHCP server. Wireless electric power meters The wireless electric power meter prototype is shown in Fig. 3. It has a plug that can be inserted in a standard wall socket, and provides a socket on the backside, where the electrical load to be monitored can be inserted. Measured information includes active, reactive, and apparent power; power factor; sampled waveforms; RMS
•
c) Fig. 3. a): Prototype of the wireless electric power meters. b): detail of the board (Zigbee module radio to be connected on top via the MCU connector) c) Block diagram of the power meter.
Our prototype uses a Freescale MC13224 SoC for ZigBee communication, consisting of an ARM7 processor with 128 kB of Flash, 96 kB of RAM and 80 kB of ROM memory. An Analog Devices ADE7953 is used for energy measurement, and is connected to the MCU through a serial link. Calibration coefficients have been extracted with the use of a reference meter (PCE-PA 6000) and sent to the node through the ZigBee radio. After calibration, directly performed
by the MCU, the ZigBee smart meter has an accuracy of 1.1%. Load switching is done with a single pole bistable 12 V relay supporting up to 16 A. The board also includes a power supply unit, providing 3 V and 12 V for operation. We have performed several comprehensive tests of the implementation to verify operation and reliability. A complete demonstrator including more than 10 sensors has run continuously for more than three months without data loss in a laboratory setting, with quasi-daily addition and removal of smart meters. As an example, data extracted from the demonstrator in a time span of about three hours from three smart meters are plotted in Fig. 4. Data from a small refrigerator, an electric heater, and an expresso coffee maker show the typical features of the corresponding power loads.
measured effective number of bits (ENOB) of 14, which is much larger than present day systems [12].
Fig. 5. Top: ECG Belt. Bottom: ECG board
Fig. 4. Power consumption data collected from 3 common household loads and partial sum.
• Wearable ECG Monitoring A second demonstrator of the measurement platform comprises a data acquisition system of wearable ECG sensors, for health monitoring or fitness monitoring applications. Each wearable sensor node consists of a battery-powered chest belt enabling a real-time electrocardiogram during daily routines. Two dry plastic electrodes and the electronic circuit are integrated into the belt (Fig. 5). The circuit extracts, filters, amplifies and digitizes the ECG signal, and then sends it to the IoT server through the gateway.
The signal is sampled at 320 Hz, and digitally filtered by a linear-phase finite impulse response filter in the ADS1246 with a cutoff frequency of 153 Hz. Data are collected by the MCU through the SPI and then transmitted in ZigBee packets. Before the transmission, the sampled values are delta encoded and compressed with an entropy encoding algorithm [13]. This simple compression scheme leads to a data reduction of about 50%. 80 bytes of encoded data (corresponding to a variable number of samples) are then sent with each ZigBee packet (each ECG sensor must transmit about 2.5 packets/s).
Our ECG node has a one-lead analog front end, with no driven leg circuit and no reference electrode. Both are not required for a floating close-body-coupled ECG system. The main circuit blocks are shown in Fig. 6, and include a band pass filter (0.05 Hz – 160 Hz), an analog-to-digital converter, a digital filter, a power management block, and the MC13224 (including the MCU and a ZigBee Radio). The first stage of the input band-pass filter is a first-order high-pass filter with 0.1 Hz cut-off frequency, to partially suppress baseline wander. Residual baseline wander can then be suppressed after analog-to-digital conversion using digital algorithms. The ADC is a 24-bit TI ADS1246, powered at 3 V, which also integrates a low-noise programmable gain instrumentation amplifier (PGA). We set the gain to 128, which provides an input-referred noise of 0.43 µVRMS, a maximum input signal of 23 mV, a CMRR larger than 110 dBm. This choice provides a
Fig. 6. ECG circuit block diagram
The ECG circuit has been realized as a standard two-layer PCB (Fig. 5). Two electrode buttons connect the board to commercial strap commonly used for heart rate measurement. The ECG board has a printed F-antenna and the output power is set to 0 dBm while the receiver sensitivity is about -96 dBm. The board dimensions are 65 mm x 34 mm x 17 mm (comprising electrode buttons and battery). An experimental deployment of the system has been used to assess key aspects of the system architecture, in particular
the possibility of monitor multiple patients for extended time and to access ECG data though the web interface. The system setup included a few ECG sensor nodes, a ZigBee gateway and an IoT server. The signal waveform (Fig. 7) has a very good quality, with clearly identifiable QRS complex, P and T waves, and ST segment. Range tests has been performed both outdoor than indoor confirming the ZigBee range of 30 m indoor and more than 70 m outdoor.
applications, and we have demonstrated two relevant use cases, for low and medium data rate. TABLE 1: ECG AVERAGE LOSS RATES AT 320 HZ SAMPLING RATE
ECG Devices
No Compr. ACK
1
0.0%
No Compr. No ACK 0.0%
Compr. ACK 0.0%
Compr. No ACK 0.0%
2
1.53%
0.32%
1.56%
0.12%
3
5.03%
1.83%
4.76%
0.52%
4
14.11%
3.32%
7.79%
1.91%
5
18.10%
5.80%
10.9%
2.44%
6
-
7.99%
-
4.69%
TABLE 2: ECG AVERAGE LOSS RATES AS A FUNCTION OF SAMPLING RATE WITH COMPRESSION AND NO ACK
320 Hz
160 Hz
80 Hz
40 Hz
1
0,00%
0,00%
0,00%
0,00%
2
0,12%
0,00%
0,00%
0,00%
3
0,52%
0,19%
0,00%
0,00%
4
1,91%
0,51%
0,16%
0,16%
5
4,09%
0,95%
0,39%
0,33%
6
4,69%
1,87%
1,06%
0,44%
ECG
Fig. 7. ECG signal waveform
According to measurements, battery life in continuous operation using a lithium 3 V battery with 650 mAh true capacity (CR2450) is then 132.71 hours (>7 days). Other proposed solutions with point-to-point communication are only able to assure a battery life of about 28 hour sampling at 300 Hz and 8-bit of resolution and transmitting them through ZigBee [14], or a lifetime of 33 hours sending ECG data through Bluetooth [15]. To measure the packet loss in multiuser ECG monitoring and determine the maximum number of ECG belt that can be reliably connected to a single gateway, we deployed a star network without routers. Four test configurations have been performed: with and without data compression, and with and without acknowledgement (ACK) mechanism. During each test, numerous acquisitions of 10 minute each have been done. In Table 1, the average packet loss as a function of the number of concurrent ECG devices is shown, for each test configuration. The average packet loss is the ratio of the number of packets not successfully delivered to the gateway to the number of messages generated by all ECG devices. Table 1 shows that the acknowledge mechanism increases data loss for medium data rate sensors, while the use of compression algorithm strongly increases the number of ECG devices for a given packet loss rate. In Table 2, we case see that packet loss rate is strongly dependent on the sampling rate, i.e. on the data rate of each sensor. IV. RELATED WORK AND DISCUSSION In this paper, we have presented an IoT infrastructure that can be used as a platform for distributed measurement
Fc
Our proposed architecture enables the seamless integration of different types of sensors and communication protocols, and has low marginal costs of adding a new type of sensor to the network. Although there are a few proposals in this field, most of them connect a home sensor or automation network to the wide area network or to a central server by means of a complex gateway, with large computational power (several MB of RAM and FLASH and a complete operating system) [19], [20]. Communication can occur for example via ZigBee and 6LoWPAN [18], [19], or via dedicated radio links [16] [20] that require expert technicians for installation. Ref. [19], [21] and [22] implement the data storage, analysis and user interface by means of a local server, assigning to the user the task to maintain and configure the system. With respect to these papers, our proposed architecture has two main advantages: • It is intrinsically suitable to large-scale deployment, because of the low-cost gateways (bill of material smaller than 15$), and of the ease of deployment by non-technical users. • Concurrent applications and experiments, run by different users, can coexist on the same measurement infrastructure, enabling either confidentiality or data sharing
TABLE 3: PERFORMANCE SUMMARY COMPARISON BETWEEN OUR PROPOSED ECG SENSOR AND OTHER RECENT SIMILAR WORKS
[7]
FACTOR
[23]
[24]
[15]
[25]
This Work
ADC (bits) fs (Hz) fL (Hz) fH (Hz) CMRR (dBm)
10 200 n/a n/a 60
12 250 0.5 125 99
12 512 0.05 150 n/a
10 500 0.5 85 60
14 (ENOB) 320 0.1 153 > 112
DLR circuit
n/a
YES
YES
YES
NO
Simplici TI
no TX
BT
ANT
Packet Loss
