Design and Implementation of Middleware for IoT Devices toward Real-Time Flow Processing

Full text

Design and Implementation of Middleware for IoT
Devices toward Real-Time Flow Processing
Yugo Nakamura1, Hirohiko Suwa1, Yutaka Arakawa1, Hirozumi Yamaguchi2, Keiichi Yasumoto1
1Nara Institute of Science and Technology, Ikoma, Nara 630-0192, Japan
2Osaka University, Suita, Osaka 565-0871, Japan
Email: {nakamura.yugo.ns0, yasumoto}@is.naist.jp
Abstract—Thanks to rapid advance and penetration of IoT
devices, it is becoming possible to sense almost every information
of real-world. This urges us to utilize data streams continuously
generated from IoT devices in real-time. In this paper, aiming to
locally process data streams by using computational resources of
IoT devices, we propose middleware for IoT devices where the
devices process data streams in real-time and in a distributed
manner. The proposed middleware provides four functions: (1)
distribution of tasks issued by application software into sub-
tasks and distributed execution of the sub-tasks over multiple
IoT devices, (2) distribution of data streams over IoT devices, (3)
real-time analysis of the data streams, and (4) seamless integration
of sensors and actuators. We have implemented a prototype of
the proposed middleware for Raspberry Pi and show its basic
performance.
I. INTRODUCTION
Recently, Internet of Things (IoT) that connects small
devices like sensors and actuators through network has been at-
tracting much attention due to its large potential for drastically
changing our society. IoT allows us to easily obtain sensor data
and even videos representing real-world situations. Thereby, a
way of creating situation-adaptive IoT services is required to
strategically utilize IoT data streams and improve quality of
life of people as well as values of communities.
In IoT and big data research fields, researchers were
focusing on development of technologies that efficiently collect
and aggregate various and massive sensor data. Therefore,
most of existing IoT-based systems employ cloud-centered
architecture as shown in the left-up side of Fig. 1. In this
architecture, data streams by IoT devices are collected and
stored in large-scale storage in cloud and analyzed spending
huge time and computation power before the analysis result
is fed back to the real-world. This kind of cloud-centered
architecture is not suitable to realize IoT services requiring
frequent communication among devices and real-time feedback
because such an architecture is not efficient and takes a lot
of cost to upload massive data streams from IoT devices
to the cloud. Moreover, community-based IoT services may
have to deal with privacy-sensitive data of community and
local residents, which should be kept within their private IT
infrastructure.
Assuming that computation power and memory capacity of
IoT devices increase year by year, we think IoT data streams
should be processed near their sources as shown in the right-
up side of Fig. 1. In [1], we proposed a platform called
IFoT (Information Flow of Things) that efficiently performs
New framework for IoT data streams
App_1 App_2 App_3 App_4
App_A App_B App_C
Conventional framework for IoT data streams
(Cloud-based centralized architecture)
Large
delays
Off-line utilization of stored big data
Real-time utilization of IoT data streams
Fig. 1. Paradigm shift of IoT-based systems
distributed processing as well as distribution and analysis of
data streams near their sources.
In this paper, aiming to locally process data streams by us-
ing computational resources of IoT devices based on “Process
On Our Own (PO3)” concept, we design and implement the
IFoT middleware for IoT devices where those devices process
data streams in real-time and in a distributed manner. The IFoT
middleware provides four functions: (1) distribution of tasks
issued by application software into sub-tasks and distributed
execution of the sub-tasks over multiple IoT devices, (2)
distribution of data streams over IoT devices, (3) real-time
analysis of the data streams, and (4) seamless integration of
sensors and actuators.
The remainder of the paper is organized as follows. Sec-
tion 2 overviews the related research and Section 3 clarifies
requirements and shows applications of IFoT middleware. The
detailed design of the middleware are described in Section
4 and its prototype implementation and basic performance
evaluation are provided in Section 5. Finally, we conclude the
paper in Section 6.
2016 IEEE 36th International Conference on Distributed Computing Systems Workshops
/16 $31.00 © 2016 IEEE
DOI 10.1109/ICDCSW.2016.37
162

II. RELATED WORK
Various IoT platforms have been designed and imple-
mented to interconnect IoT devices and process / merge data
streams [2]. Arkessa [3], Axeda [4], ThingSquare [5], Thing-
worx [6], WoTkit [7] and Xively [8] are PaaS (Platform as
a Service)-based architecture relying on cloud services, while
OpenIoT [9] and LinkSmart [10] are designed as distributed
systems. However, those platforms focus on data stream ag-
gregation above the cloud or support for service development
and have not yet achieved the context-based decentralized
data stream processing, which is the primary focus of IFoT.
Although IoT gateways have been designed and developed in
recent years [11], [12], [13], they also rely on cloud servers.
Edge Computing [14] [15] and Fog Computing [16] are
new paradigms where data processing is executed on those
components in or on the edge of networks to mitigate server
load. The demerit of these approaches is the need for invest-
ment to replace such network constituents like Information-
Centric networks (ICNs). We consider a more practical so-
lution by extending Edge Computing and Fog Computing.
We delegate the processing tasks of cloud servers to other
distributed systems to enable distributed real-time stream pro-
cessing.
Recently, stream processing technologies have been investi-
gated where multiple continuous data streams from sensors are
adaptively merged and aggregated to respond to given requests
of analysis and event detection over those streams. The existing
technologies are categorized by their processing styles where
(i) a single point of aggregation is assumed [18], [19] and (ii)
a fully distributed style is employed [20]. In this paper, we
take the distributed processing approach, which aim to realize
real-time stream processing.
In event detection and data analysis perspective, different
frameworks have been developed. In particular, on-line ma-
chine learning is a key enabler to realize real-time event detec-
tion and data analysis. Many of the IoT platforms support on-
line learning schemes. For example, AWS and StreamInsight
provide Amazon Machine Learning [21] and Azure Machine
Learning [22] to enable data processing and analysis over data
streams. SAMOA [23], MLlib [24], Jubatus [25] and Oryx [26]
also provide on-line machine learning functions. In this paper,
we use Jubatus that has a powerful distributed on-line machine
learning capability. We would like to highlight that our focus is
to realize distributed stream fusion using service-level context
on such a platform like Jubatus.
With the increased capabilities of wireless sensor nodes,
WSNs are becoming powerful enough such that sensors are
able to communicate with each other to accomplish more com-
plicated tasks. However, most of such in-network processing
approaches on WSNs like [17] have considered lightweight
data processing, while our focus is on data streaming and
real-time processing, where different design issues like task
allocations and stream aggregation should be considered.
III. REQUIREMENTS FOR THE MIDDLEWARE
A. Target application and functional requirements
The feature of IFoT middleware is that it is deployed near
the data source and works without any cloud system. All the
sensor streams are processed among proximity devices running
IFoT middleware without being stored in the database. This
architecture is suitable for real-time applications. Below, we
explain the functional requirements showing some examples
of applications.
1) Elderly monitoring application: This application keeps
monitoring elderly persons by analyzing sensor data streams
from various sensors deployed in their living environments. It
realizes an on-site tracking service that can detect emergency
situations like a bone fracture by fall.
In order to realize this application, the system has to
analyze sensor data streams generated from various sensors in
real-time for detecting the anomaly. In other words, the func-
tions to distribute and analyze multiple data streams between
multiple sensor devices are required.
2) Context-aware home appliance control application:
This application monitors the environment by utilizing various
environmental sensors such as illuminance sensors, sound
sensors and motion sensors. Based on the sensing results,
it provides a comfortable environment by controlling various
home appliances such as an air conditioner and ceiling light.
In order to realize this application, the system has to
estimate the environment of the place by combining the sensing
values of various sensors. In addition, it must quickly control
the home appliances based on the estimation results. It means
that the inter-node stream distribution and high-level data
analysis functions as well as the seamless cooperation among
various sensing devices and actuators are required.
3) Context-aware mobility support application: This ap-
plication estimates the crowdedness and the scenic beauty of
the PoI (Point of Interest) by sensing the person flow and
movement and so on for realizing the context-aware navigation
service that efficiently navigates users to a good PoI taking
into account its current conditions (e.g., crowdedness, scenic
beauty, etc.) of roads and spots. In this application, car-
mounted camera, smartphones, and environmental sensors in
the city are utilized for the estimation.
In order to provide such an integrated service, multiple
services should be utilized. For example, by making our Sakura
sensor [27] and crowd sensing technology [28] integrated, we
can estimate the correlation of the popularity and scenic levels,
which creates new services for the visitors. To do so, the
middleware should control high-level data streams as well as
low-level IoT devices.
B. Problem statement and basic approach
Some related applications which utilize the local processing
resources instead of a cloud resource have been proposed.
However, most of them are not good at sharing the sensor
devices or reusing the sensor data between different systems,
because the architecture of these applications is a vertically
integrated system. It increases the cost of the system, because
the system developer has to start from the selection of sensors
and actuators. On the other hand, in the research field of
wireless sensor network, some platforms [29] and middleware
[30] that can run multiple applications on the local sensor
devices have been proposed. However, these systems only
support the dedicated devices of each system. In addition,
163

executable processes are limited to the simple sensing and data
transmission, and complicated tasks such as anomaly detection
and clustering are not supported.
Our IFoT middleware aims to realize a horizontally-
distributed platform that allows various applications to share
IoT data streams generated from various sensors deployed in
our environment. Therefore, it provides the function to run
multiple tasks in parallel by dividing the original task, and also
provides the function to distribute the data streams directly
according to the requirement of devices. In addition, online
data analysis function and inter-node cooperation function for
connecting different sensors and actuators are also provided.
IV. IFOTMIDDLEWARE
In this section, we design middleware for Information Flow
of Things (IFoT) [1], a framework for processing, analyzing,
and aggregating (curating) IoT data streams in real-time and in
a scalable manner based on distributed processing among IoT
devices. IFoT middleware is an abstraction software running
on the intelligent sensing device (a flow source) which captures
and processes data in the real world and sends them out as a
flow(s). IFoT middleware has communication capabilities with
nearby IFoT nodes and the Internet (optional), and basic stream
processing such as data cleansing, data aggregation, etc.
A. Assumed Environment
Figure 2 shows the operating environment of IFoT mid-
dleware. We define (a) sensor node as a device to collect
information of the real environment, (b) actuator node as a
device to affect people, objects, space in the real environment,
and (c) IFoT Neuron Module as a small computer running IFoT
middleware for processing data streams. IFoT neuron mod-
ule has short-range wireless communication (Bluetooth Low
Energy, Enocean [31], Zigbee, etc.) interfaces for connecting
to the sensors / actuators and optional long range wireless
communication (WiFi, LTE, etc.) interfaces for connecting
to the Internet. Flows (or data streams) can be transmitted
between neuron modules.
B. Basic Concept
Figure 3 shows the layered architecture of IFoT systems,
where a system is divided into three layers: Application layer,
IFoT neuron layer, and Sensor / Actuator layer. IFoT middle-
ware runs over IFoT neuron modules and performs processing
/ analyzing / distributing the generated IoT data streams and
operates in response to a request from the application layer.
The functions of the IFoT middleware are described below.
1) Distributed processing of tasks: In accordance with the
requests of each application, IFoT middleware assigns tasks to
each node. Each node executes the assigned tasks depending
on the processing capability.
2) On-demand flow distribution: In an environment where
a variety of IoT data streams are generated, it is not efficient to
send all of the raw data to the cloud system. Therefore, IFoT
middleware provides the capability of direct flow distribution
between devices in parallel.
Sensor node
（Sensor + Short-range communication I/F ）
Actuator node
（Actuator + Short-range communication I/F )
IFoT neurons modules
(Small computer + IFoT Middleware
+ Long/Short-range communication I/F)
Real Environment
Fig. 2. Assumed Environment of IFoT system
Real Environment
Sensor/Actuator Layer
IFoT Neuron Layer
Application Layer
②Distribute
③Analysis
①Assignment of tasks
Application A Application B Application C
IFoT Middleware
Fig. 3. Layered architecture of IFoT system
3) Online information processing: In IFoT systems, real-
time utilization of IoT data streams is required. Therefore,
IFoT middleware provides the ability to quickly processing /
analyzing / aggregating IoT data streams without accumulating
/ storing.
4) Various data streams integration: In assumed environ-
ment, there are variety of sensors / actuators that have different
interfaces and communication standards. Therefore, IFoT mid-
dleware provides the capability of handling the various data
streams in a unified manner.
C. Architecture
Figure 4 shows the logical architecture of IFoT middleware.
Figure 5 shows Recipe, that is a configuration file describing
a processing procedure of IoT data streams. In particular, it
is described as a task graph showing the processing procedure
(how to process and analyze the data streams, how to integrate
multiple data streams into a flow). Functions of the IFoT
middleware are explained below.
1) Task allocation function: Task allocation function is
composed of a recipe split class and task assignment class.
Recipe split class reads the recipe of among application and
divides it into tasks that can be executed in parallel. Task
assignment class distributes the divided tasks to among IFoT
modules.
2) Flow analysis function: Flow analysis function is com-
prised of learning class, judging class, managing class. Learn-
ing class analyzes a time series of sensor data in a sequential
164

Application A Application B Application C
IFoT Middleware
Recipe A Recipe B Recipe C
①Task allocation mechanism
②Flow analysis mechanism
３∼４ページ
④Sensor/actuator integration mechanism
Sensor Class Actuator Class
Sensor node Actuator node
Task assignment ClassRecipe split Class
③Flow distribution mechanism
Publish Class Broker Class Subscribe Class
Learning Class Judging Class Managing Class
Fig. 4. Logical architecture of IFoT middleware
Start watching
Sensing A Sensing B Sensing C
Anomaly detection
Sensing D
Anomaly detection
Camera monitoring
State estimation
Alert messaging
Fig. 5. Image of Recipe
order, and builds / updates models. Judging class analyzes data
streams using the built model. Managing class manages the
cooperative operation for distributed processing.
3) Flow distribution function: Flow distribution function
is comprised of publish class, broker class, subscribe class. In
IFoT middleware, the publish / subscribe system is adopted for
flow distribution between IFoT nodes, aiming to realize loosely
coupled flows and scalable messaging. Publication class is
placed in the sending side, subscription class is placed in the
receiving side in communication between IFoT nodes. Broker
class manages the distribution of data in accordance with the
topic the subscription class specifies.
4) Sensor / actuator integration function: Sensor / actuator
integration function is comprised of a sensor class and actuator
class. Each class abstracts the hardware and the communication
interface of the sensor / actuator, and provides a common
interface to flow distribution function. For example, a variety
Step1 : Submit Recipe
Step2 : Divide Recipes, Task Assignment
Step3 : Application execution
Application A
Assign
Application A
Recipe A
Divided
Fig. 6. Application building process
Management Node
IFoT Neuron Module
Wireless LAN
Management software
IFoT Middleware
Module A
IFoT Middleware
Module B
IFoT Middleware
Module C
IFoT Middleware
Module D
IFoT Middleware
Module E
IFoT Middleware
Module F
Fig. 7. Evaluation system structure
of sensor data streams are converted to packets of Message
Queue Telemetry Transport (MQTT) protocol [32].
D. Application build process
An overview of the application building process using the
IFoT middleware is shown in Figure 6. In Step 1, Application
builder makes the recipe, and sends the recipe to an IFoT
module. In Step 2, the IFoT module reads the recipe, divides
it into tasks that can be performed in parallel. In Step 3,
IFoT modules instantiate the class according to the contents
of the recipe, and execute the operation of the application in
cooperation with each other.
V. I MPLEMENTATION AND EVALUATION
A. Implementation
We implemented a prototype of IFoT middleware with
limited functions: flow distribution function and flow analysis
function. The flow distribution function is developed based
on Mosquitto [33] that has a lightweight communications
scheme by MQTT protocol. The flow analysis function is
165

TABLE I. EQUIPMENT SPECIFICATION
Device Raspberry Pi 2
Neuron OS Raspbian
Module CPU ARM Cortex-A7 900MHz
Memory 1GB
Device Think pad x250
Management OS Ubuntu 14.04
Node CPU Core i5-5200U 2.2GHz
Memory 8GB
Fig. 8. Management software screen
developed based on Jubatus that has a powerful distributed
on-line machine learning capability.
B. Overview of Experiments
The purpose of this experiment is to evaluate the perfor-
mance of the IFoT middleware and confirm the feasibility of
the IFoT based System. For this experiment, prototype of the
IFoT middleware is installed in six Raspberry Pis. Throughout
the experiment, we measured the processing time in the data
distribution and analysis by the IFoT middleware. Then, we
confirmed the trend in the processing delay (From the Sensing
to Training, Sensing to Predicting) by changing generation rate
of the sensor data (5, 10, 20, 40, and 80Hz.).
The system used in the experiment is shown in Figure
7. The equipment specifications are also shown in Table
I. The system is composed of six IFoT neuron prototypes
(Raspberry Pi) and one of the experimental management node.
All modules are connected to a common wireless LAN. In the
experiment, the class running on each module is selected from
the management software (Figure 8) on the management node.
TABLE II. EXPERIMENTAL RESULT(SENSING-TRAINING)
Sampling
rate(Hz)
Time(ms)
Ave. Max
5 58.969 357.619
10 60.904 360.761
20 232.944 419.513
40 1123.317 1482.500
80 1636.907 1913.752
Sensor Class Sensor ClassSensor Class
Publish ClassPublish Class Publish Class
Pub(A,data) Pub(B,data) Pub(C,data)
Sub(A,B,C)Sub(A,B,C)
Model
Pub(A,B,C,[data])
Train Class
[data]
Judgment result
data data data
Actuator Node
IFoT Neuron Module
[data]
Pub(A,B,C,[data])
Broker Class
Sensor Node
Module A Module B Module C
Module D
Module FModule E
Sample sensor data are transmitted at each fixed rate (5,10,20,40,80Hz).
Measuring the time until the end of
①Training process and ②Predicting process by Jubatus.
Actuator Class
Predict Class
Subscribe Class
Subscribe Class
①Training process
Sensor Class -> Publish Class -> Broker Class -> Subscribe Class -> Train Class
②Predicting process
Sensor Class -> Publish Class -> Broker Class -> Subscribe Class -> Predict Class
Fig. 9. Cooperation between classes in the experiment
Linked operation between the modules is setup by management
software. The management software is developed based on
OpenRTM-aist [34]. As shown in Figure 9, we measured
processing time until completing each process ((1) learning
process, (2) predicting process) from sensing time. Sensor data
(32byte) are generated on the three neuron modules.
C. Experimental Results
Tables II and III show the results of the delay time in
learning and predicting processes for different sensing rate. In
the case of low sensing rate such as 10 and 20Hz, IFoT mid-
dleware could realize low-latency (i.e., real-time) processing.
When sensing rate is 20 to 40Hz, the delay time increased
and real-time processing was no longer possible. Then, in the
case of sensing rate over 80Hz, the delay time increased much
more. These results indicate that the current IFoT middleware
prototype can achieve real-time processing in a small-scale.
TABLE III. EXPERIMENTAL RESULT(SENSING-PREDICTING)
Sampling
rate(Hz)
Time(ms)
Ave. Max
5 58.969 346.142
10 59.020 334.501
20 74.747 373.992
40 744.535 819.748
80 1144.580 1249.122
166

However, in order to realize the real-time processing in a
larger-scale environment, it is necessary to add furether /
parallelization decentralization of processing tasks according
to available resources.
VI. CONCLUSION
In this paper, we proposed a middleware for IFoT (Infor-
mation Flow of Things) platform where IoT devices cooperate
to process flows or data streams in real-time, based on the
“Process On Our Own (PO3)” concept. IFoT middleware aims
to realize that (a) multiple applications run on IoT devices
while sharing their resources and (b) contents composed by
processing / analyzing / merging data streams in each ap-
plication can be distributed for secondary / tertiary use in
real-time. For these purposes, the middleware provides four
functions, (1) task division and allocation to IoT devices, (2)
on-demand distribution of data streams among IoT devices, (3)
real-time analysis of data streams, and (4) seamless integration
of sensors and actuators. We designed IFoT middleware and
implemented its prototype. We also conducted a simple exper-
iment for basic performance evaluation using six Raspberry
Pis. As a result, we confirmed that the proposed middleware
can realize real-time processing and analysis of data streams.
As the next step, we will improve real-time processing
performance and scalability of the IFoT middleware. Definition
of the language to describe recipes as well as the search
function for data streams generated from IoT devices that can
dynamically join / leave the network are also part of future
work.
Acknowledgement
This work was supported in part by JSPS KAKENHI Grant
Numbers 16H01721 and 26220001.
REFERENCES
[1] K. Yasumoto, H. Yamaguchi, H. Shigeno: Survey of Real-time Pro-
cessing Technologies of IoT Data Streams, Journal of Information
Processing, Vol. 24, No. 2, pp.195-202, 2016.
[2] J. Mineraud, O. Mazhelis, X. Su, S. Tarkoma: Contemporary Internet
of Things platforms, arXiv Preprint arXiv:150107438, 2015.
[3] Arkessa, http://www.arkessa.com/. Last accessed: April 2016.
[4] Axeda, http://www.axeda.com/. Last accessed: April 2016.
[5] ThingSquare, http://www.thingsquare.com/. Last accessed: April 2016.
[6] Thingworx, http://www.thingworx.com/. Last accessed: April 2016.
[7] M. Blackstock, R. Lea: IoT mashups with the WoTKit, in Proceedings
of IEEE Internet of Things (IOT), pp. 159–166, 2012.
[8] Xively, http://xively.com. Last accessed: April 2016.
[9] J. Kim and J.-W. Lee: OpenIoT: An open service framework for
the Internet of Things, in IEEE World Forum on Internet of Things
(WFIoT), pp. 89–93, 2014.
[10] P. Kostelnik, M. Sarnovsk, and K. Furdk: The semantic middleware
for networked embedded systems applied in the internet of things and
services domain, Scalable Computing: Practice and Experience, vol. 12,
pp. 307-315, 2011.
[11] Q. Zhu, R. Wang, Q. Chen, Y. Liu, and W. Qin: IoT gateway: bridging
wireless sensor networks into internet of things, in Proceedings of
IEEE/IFIP 8th International Conference on Embedded and Ubiquitous
Computing (EUC), pp.347–352, 2010.
[12] T. Zachariah, N. Klugman, B. Campbell, J. Adkins, N. Jackson, and
P. Dutta : The internet of things has a gateway problem, ACM
HotMobile’15 , pp. 27–32, 2015.
[13] S. Choochotkaew, H. Yamaguchi, T. Higashino, M. Shibuya: Data
Prioritization at Multi-user IoT Gateway with Multiple Sensor Data
Attributes, DPSWS bulletin, Vol. 5, pp.53–61, 2015.
[14] A. Davis, J. Parikh, W. E. Weihl: Edgecomputing: extending enterprise
applications to the edge of the internet, Proc. the 13th international
World Wide Web conference on Alternate track papers and posters,
2004.
[15] Pedro Garcia Lopez, Alberto Montresor, Dick Epema, Anwitaman
Datta, Teruo Higashino, Adriana Iamnitchi, Marinho Barcellos, Pascal
Felber, and Etienne Riviere : Edge-centric computing: Vision and chal-
lenges, ACM SIGCOMM Computer Communication Review, Vol.45,
No.5, pp.37-42 , 2015.
[16] F. Bonomi, R. Milito, J. Zhu, S. Addepalli: Fog Computing and Its
Role in the Internet of Things, Proc. of the First Edition of the MCC
Workshop on Mobile Cloud Computing (MCC ’12), pp. 13–16, 2012.
[17] D. Alessandrelli, M. Petraccay, and P. Pagano: T-Res: Enabling Recon-
figurable In-network Processing in IoT-based WSNs. Proc. of the 2013
IEEE International Conference on Distributed Computing in Sensor
Systems, pp. 337–344, 2013.
[18] S. Dutta, A. Narang, and S. K. Bera: Streaming Quotient Filter: A Near
Optimal Approximate Duplicate Detection Approach for Data Streams,
Proc. of the VLDB Endowment, Vol. 6, No. 8, pp. 589–600, 2013.
[19] Q. Zhang, J. Liu, and W. Wang: Approximate Clustering on Distributed
Data Streams, Proc. of the International Conference on Data Engineer-
ing (ICDE2008), pp. 1131–1139, 2008.
[20] C. Lei, E. A. Rundensteiner, and J. D. Guttman: Robust Distributed
Stream Processing, Proc. of the International Conference on Data
Engineering (ICDE2013), pp. 817–828, 2013.
[21] Amazon Machine Learning，https://aws.amazon.com/machine-
learning/. Last accessed: April 2016.
[22] Azure Machine Learning，https://azure.microsoft.com/en-
us/services/machine-learning/. Last accessed: April 2016.
[23] Apache SAMOA，https://samoa.incubator.apache.org/. Last accessed:
April 2016.
[24] Spark MLib，http://spark.apache.org/mllib/. Last accessed: April 2016.
[25] Jubatus，http://jubat.us/en/. Last accessed: April 2016.
[26] Cloudera Oryx, https://github.com/cloudera/oryx. Last accessed: April
2016.
[27] S. Morishita, S. Maenaka, D. Nagata, M. Tamai, K. Yasumoto, T.
Fukukura, and K. Sato: SakuraSensor: a system for realtime cherry-
lined roads detection by in-vehicle smartphones, Proc. of the 2015 ACM
International Joint Conference on Pervasive and Ubiquitous Computing
(UbiComp 2015), pp. 695–705, 2015.
[28] T. Nishimura, T. Higuchi, H. Yamaguchi, T. Higashino: Detecting
smoothness of pedestrian flows by participatory sensing with mobile
phones, Proc. of the 2014 ACM International Symposium on Wearable
Computers (ISWC 2014), pp.15-18, 2014.
[29] J. Hill and D. Culler: MICA: A wireless platform for deeply embedded
networks, IEEE Micro, vol. 22, pp. 12–24, 2002.
[30] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K.Pister:
System architecture directions for networked sensors, Proc. of the 9th
International Conference on Architectural Support for Programming
Languages and Operating Systems, pp. 93–104, 2000.
[31] Enocean, https://www.enocean.com/en/. Last accessed: April 2016.
[32] MQTT，http://mqtt.org/. Last accessed: April 2016.
[33] Mosquitto, http://mosquitto.org/. Last accessed: April 2016.
[34] N. Ando, T. Suehiro, K. Kitagaki, and T. Kotoku: A Software Platform
for Component Based RT-System Development: OpenRTM-Aist, Proc.
of SIMPAR 2008, pp. 87–98, 2008.
167