=Paper=
{{Paper
|id=None
|storemode=property
|title=Context Aware Sensor Configuration Model for Internet of Things
|pdfUrl=https://ceur-ws.org/Vol-1035/iswc2013_poster_19.pdf
|volume=Vol-1035
|dblpUrl=https://dblp.org/rec/conf/semweb/PereraZCCG13
}}
==Context Aware Sensor Configuration Model for Internet of Things==
https://ceur-ws.org/Vol-1035/iswc2013_poster_19.pdf
Context Aware Sensor Configuration Model for
Internet of Things
Charith Perera1,2 , Arkady Zaslavsky2 , Michael Compton2 , Peter Christen1 ,
and Dimitrios Georgakopoulos2
1
Research School of Computer Science, The Australian National University,
Canberra, ACT 0200, Australia
{charith.perera, peter.christen}@anu.edu.au,
2
CSIRO ICT Center, Canberra, ACT 2601, Australia
{charith.perera, arkady.zaslavsky, michael.compton
dimitrios.georgakopoulos}@csiro.au
Abstract. We propose a Context Aware Sensor Configuration Model
(CASCoM) to address the challenge of automated context-aware config-
uration of filtering, fusion, and reasoning mechanisms in IoT middleware
according to the problems at hand. We incorporate semantic technologies
in solving the above challenges.
1 Introduction
Broadly, configuration in IoT paradigm can be categorized into two: sensor-level
configuration and system-level configuration. Sensor-level configuration focuses
on changing a sensor’s behaviour by configuring its embedded software param-
eters such as sensing schedule, sampling rate, data communication frequency,
communication patterns and protocols. In this paper, we are focused on devel-
oping a system-level configuration model for IoT midddleware platforms. Specif-
ically, our proposed model identifies, composes, and configures both sensors and
data processing components according to the user requirements. In existing IoT
middleware (e.g. GSN), many configuration files and programming codes need
to be manually defined by the users (without any help from GSN). An ideal IoT
middleware configuration model should address all the above mentioned chal-
lenges. The configuration model we propose in this paper is applicable towards
several other emerging paradigms, such as sensing as a service [4].
2 Problem Analysis
Our research question is ‘How to develop a model that allows non-IT experts
to configure sensors and data processing mechanisms in an IoT middleware ac-
cording to the user requirements?’. Extended explanations are provided in [3].
Research challenges are highlighted in Figure 1. Context-Aware Sensor Config-
uration Model (CASCoM) simplifies the IoT middleware configuration process
significantly. Figure 2 compares the execution-flow of sensor configuration in
the current GSN approach and the CASCoM approach. The proposed solution
CASCoM is illustrated in Figure 3.
User does not know which
sensors to use to retrieve data
A user wants to Our objective is
monitor / detect User does not know how to to help the user
/ discover configure the IoT middleware to overcome
a phenomenon these challenges
User does not know which data
processing components to use
Fig. 1. Research Challenges, User Requirements, and Our Objective
3 The CASCoM Architecture
In phase 1, users are facilitated with a graphical user interface, which is based on
a question-answer (QA) approach, that allows to express the user requirements.
Users can answer as many question as possible. CASCoM searches and filters the
tasks that the user may want to perform. From the filtered list, users can select
the desired task. The details of the QA approach are presented later in this
section. In phase 2, CASCoM searches for different programming components
that allow to generate the data stream required. In phase 3, CASCoM tries to find
the sensors that can be used to produce the inputs required by the selected data
processing components. If CASCoM fails to produce the data streams required
by the users due to insufficient resources (i.e. unavailability of the sensors),
it will provide advice and recommendations on future sensor deployments in
phase 4. Phase 5 allows the users to capture additional context information.
The additional context information that can be derived using available resources
and knowledge are listed to be selected. In phase 6, users are provided with one
or more solutions3 . CASCoM calculates the costs for each solution in using
technique disucced in [2]. By default, CASCoM will select the solution with
lowest cost. However, users can select the cost models as they required. Finally,
CASCoM generates all the configuration files and program codes which we listed
in Figure 2(a). Data starts streaming soon after.
3
Solution is a combination of sensors and data processing components that can be
composed together in order to satisfy the user requirements.
(a) Current GSN Work-flow (b) CASCoM Work-flow
Configuration Begins Configuration Begins
Find what type (kind) sensors need to be
configured in order to solve the problems at hand Search the task and click configure
Manually find whether required types of
sensors are available to be used (optional) Discover additional context
Find out the low level details of those sensors
such as data types and measurements (optional) Receive advice on future improvements
Find wrapper details of those selected sensors
(optional) Optimize the configuration
Manually search for appropriate data
processing components
Write the Virtual Sensor (VS), a java class,
manually by composing different data processing
components and compile the class
Write a new Virtual Sensor Definition
(VSD), a XML file, manually by referring
to correct wrappers and data types
Configuration Completes Configuration Completes
Fig. 2. Configuration Execution-flow Comparison: (a) Current GSN (b) CASCoM
Phase 1: Phase 2:
Understand User Select Data Processing
Phase 3:
Requirements Components Select Sensors
Users
Phase 6 Phase 5 Phase 4
(Optional): (Optional): (Optional):
Context-based Cost Discover Additional Provide advice and
Applications Optimization Context Recommendations
Fig. 3. The Context-Aware Sensor Configuration Model (CASCoM)
Question :hasQuestion Action :performs Task :belongsTo Domain Question
QA-TDO Classes
:hasQuestion
:performedBy
Application :supports DataStream :requires DataItem
QA-TDO
Quality : hasDataType : hasProperty
MeasurementProperty DataType Property
: hasDataType ssn: observes
Accuracy ResponseTime Sensor :connectsThrough Wrapper
SSNO Classes
:hasDataValue ssn:hasMeasurementProperty ssn:hasMeasurementCapability
DataValue MeasurementCapability
SSNO
Property (Repeat) DataItem(Repeat) Property DataItem(Repeat)
: hasProperty
: hasProperty
SCO+ Classes
Output : produces DataProcessingComponent : requires Input : hasDataType
: hasDataType : hasMainMethod
: hasPackage
: hasProcessingClass DataType
DataType Package Method
ProcessingClass
: hasProcessingCapability
Quality
MeassurementProperty
Individuals
OperatingProperty ProcessingCapability
DataValue Accuracy : hasOperatingProperty
: hasDataValue MemoryRequirement
: hasMeasurementProperty
SCO+
Fig. 4. Extracts of different ontological data models used in CASCoM: QA-TDO, SCO
[1], and SSN ontology (w3.org/2005/Incubator/ssn/wiki/SSN). These model are used
to store sensor descriptions, software component description, and domain knowledge.
4 Evaluation, Discussion and Lessons Learned
Results: Figure 5(a) shows that CASCoM allows to considerably reduce the
time required for configuration of data processing mechanism in IoT middleware.
Specifically, CASCoM allowed the three types of users to complete the given task
50, 80 and 250 times faster (respectively) in comparison to the existing approach.
According to Figure 5(b), the Java reflection approach takes slightly more time
to specially when initializing. Though the Java reflection approach can add more
flexibility to our model, the additional overhead increases when the number of
components and operation involved gets increased. The overheads can grow up
to unacceptable level very quickly when GSN scales up (e.g. more user requests).
According to Figure 5(c), even IT experts who know GSN can save time by
using CASCoM up to 88%. Specially, time taken for defining the VSD and VS
class have been significantly reduced. Both files can be generated by CASCoM
autonomously within a second even for complex scenarios. However, the time
taken to find data processing components and sensors (and wrappers) depends on
the size of the semantic data model. Figure 5(d) shows how total processing time
would vary depending on the size of the semantic data model. Approximately,
a semantic model with 10,000 sensor descriptions and 10,000 data processing
components can be processed in order to find solutions for a given user request
in less than a minute. However, most of the time is taken to read the data model.
35
(a) (b)
Time to complete the configuration (sec)
Non-IT Expert without GSN Skills (without CASCoM)
Execution (Native)
Time Taken to Process 60 data rows
IT Expert without GSN Skills (without CASCoM) 30
IT Expert with GSN Skills (without CASCoM) Execution (Reflection)
Everyone with CASCoM (Average) 25
Component Initiation (Native)
Component Initiation (Reflection)
(milliseconds)
20
15
(Logarithmic Scale)
10
5
0
Usecase (1) Usecase (2) Usecase (3) (1) (5) (10)
Different Scenarios Number of Components
70
(c) Total Processing (d)
Time take for configuration (sec)
60 Total Processing (excluding Model Reading)
15% 7% 1% 3%
50
1%
20% 51% 40
30
14% 88%
20
10
Search Wrappers Define VSD
Search Programming Components Write VS Class 0
Time Saved 0 2500 5000 7500 10000
Number of records modelled
Fig. 5. Evaluation of CASCoM
The actual configuration process other than reading the data model takes only
4 seconds and it slightly increases when the model size increases.
5 Conclusion
We have shown that it is possible to offer a sophisticated configuration model to
support non-IT experts. Semantic technologies are used extensively to support
this model. Using our proof of concept implementation, both IT and non-IT
experts were able to configure the GSN in significantly less time. In future,
we plan to extend our configuration model into sensor-level. To achieve this, we
will develop a model that can be used to configure sensors autonomously without
human intervention in highly dynamic smart environments in the IoT paradigm.
References
1. F. E. Castillo-Barrera, R. C. M. Ramı́rez, and H. A. Duran-Limon. Knowledge
capitalization in a component-based software factory: a semantic viewpoint. In
LA-NMR, pages 105–114, 2011.
2. C. Perera, A. Zaslavsky, P. Christen, M. Compton, and D. Georgakopoulos. Context-
aware sensor search, selection and ranking model for internet of things middleware.
In IEEE 14th International Conference on Mobile Data Management (MDM), Mi-
lan, Italy, June 2013.
3. C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos. Ca4iot: Context
awareness for internet of things. In IEEE International Conference on Conference
on Internet of Things (iThing), pages 775–782, Besanon, France, November 2012.
4. A. Zaslavsky, C. Perera, and D. Georgakopoulos. Sensing as a service and big data.
In International Conference on Advances in Cloud Computing (ACC-2012), pages
21–29, Bangalore, India, July 2012.