UNIVERSITY OF NOVI SAD
FACULTY OF TEHNICAL SCIENCES
SERBIA
Semantic Web Based Architecture
for Managing Hardware
Heterogeneity in Wireless Sensor
Network
Authors:
Sinisa Nikolić, MSc
Valentin Penca, MSc
Milan Segedinac, MSc
Prof. Zora Konjović, PhD
Outline
• Introduction
• Existing solutions
• GLOSENT architecture
• Case study
• Conclusion
2 of 20
Introduction
• WSN – a lot of sensor nodes(SN)
• SN – small size, low cost, batterypowered, processing, sensing, wireless
communication
• WSN is not an isolated entity
• SWSN (System of WSNs) – user
applications interact with
heterogeneous WSNs
3 of 20
Introduction (2)
• Heterogeneity of WSN appears both
in hardware and software
• Ontology based-model for solving
hardware heterogeneity in SWSN
• Specific middleware that provides
communication based on exchange
of ontologies
4 of 20
Existing solutions
• Specific based and generic (middleware)
based
Key aspects
TinyDB
WSN is a distributed database, SQL like query, TinyOS
Squawk Virtual machine (VM) based, specific application
programming language, VM for a set of hardware platforms
Impala
Event-based programing model, mobile code is written
from predefined set of instruction
Mires
Event-based, message oriented communication,
publish/subscribe paradigm, Consumer (Appliaction)/
Producer(SN), TinyOS
Table 1 – Existing middlewares
5 of 20
Existing solutions SOA
• Multi layer architecture of WSN, services
for gathering data, xml description of
hardware
• OX-Framework – using OGC standards
(describe types and usage of WSN
entities), without sematic description and
technologies
6 of 20
Existing solutions Semantic
• Raw sensor data to reconstruct the
context of event, hieratical organization
semantic information and semantic
services
• Ontologies for providing adaptive WSN
• Contextual ontologies to provide more
flexible information processing
7 of 20
GLOSENT Architecture
• GLObal SENsor neTwork
• deals with hardware heterogeneity
using semantic technologies
8 of 20
GLOSENT Architecture
Application segment
IP App App Proxy
IP SUB B
WSN segment
MIddleware
Service proxy
OWL
...
Services
Proxy
OWL
OWL
WSN Proxy A1
...
OWL
OWL
...
OWL
Services
Zone 1
XML
Services
IP SUB C
System Image
Central Storage
WSN Proxy B
Read
ings
Roles
Metadata
OWL
...
OWL
Services
Zone 2
WSN Proxy A2
OWL
IP SUB A
UserX
Figure 1 – The GLOSENT architecture
9 of 20
Application segment
• Consist of Application proxy
and Subapplications
• Subapplication – user
application that uses
appropriate communication
methods and data formats
• Application proxy – bridge
between sub placation and
other parts of system
Figure 2 – Application segment
10 of 20
WSN segment
• Role of this segment is in
gathering information and data
representation from the sensor
node network
• WSN modeled with metadata that
describe: structure, method of use
and control and data formats
• SN is a generalized notion related
to any WSN device (base stations,
rich uncles, routers, etc.)
• Uniform WSN representation
relaying on ontology
Figure 3 – WSN
segment
11 of 20
Middleware segment
• Mediates in the communication of WSN
segment and application segment in a
SWSN
• Middleware is not physical part of system,
it is consisted from data (ontologies) of all
mentioned proxies
12 of 20
System Image
• Solving hardware heterogeneity in WSN
• consists of metadata models describing different
WSN hardware platforms, metadata values
describing particular devices and their relations,
and sensor data (raw and/or aggregated sensor
readings)
• current state of all WSN, represented with
ontologies
13 of 20
System Image
hasSourceNode
Connection
SensorNode
hasDestinationNode
hasComponent
Component
hasComponent
hasMeasureUnit
MeasureUnit
hasRevision
Revision
Figure 4 – WSN ontology
14 of 20
Central storage
• Implements the data persistency
• Stores the System image data and the
information about Subapplications
SensorNode
TypeSN
REL_TypeOfSensorNode
ID
<pi> Long integer
Code
Variable characters (50)
DESCRIPTION
Variable characters (254)
LinkDocumentation
Variable characters (254)
LinkDeveloper
Variable characters (254)
...
REL_TypeSNOfProperties
REL_ParentOfTypeSNProperties
TypeSNProperties
REL_ParentOfTypeSN
REL_SensorNodeOf<IdSN>Properties
<IdSN>Properties
ID
<pi> Long integer
ID
<pi> Long integer
REVISION
Integer
Code
Variable characters (50)
VALUE
Variable characters (254)
DESCRIPTION
Variable characters (254)
STATE
Variable characters (10)
ReadOnly
Boolean
Mandatory
Boolean
Dynamic table
PropType
Variable characters (10)
Validation
Variable characters (254)
REL_TypeSNPropertiesOf<IdSN>Properties
...
<M>
<M>
<M>
<M>
ID
<pi> Long integer
Code
Variable characters (50)
DESCRIPTION
Variable characters (254)
CreatedBy
Variable characters (20)
Managed
Boolean
LastReciveUpdate
Date
REVISION
Integer
BasestationAdress
Variable characters (50)
WorkMode
Variable characters (20)
Lat
Long float
Lon
Long float
PublicAccess
Variable characters (10)
NameTableProperties
Variable characters (100)
...
Figure 5 – Central storage
15 of 20
Case study: Modeling SN in
GLOSENT
• Model of the WSN hardware platform SunSPOT
• SunSPOT is a WSN sensor node developed by
Sun Microsystems. The device was developed
based on IEEE 802.15.4 standard.
• SunSPOT can be used to measure light,
temperature and acceleration, but its
functionality can be extended with additional
sensors
16 of 20
Classification of SunSPOT
hardware components
• Some basic functionalities of SunSPOT
device
• Extensible classification
Component
SensorComponent
ProcessingComponent
SensorID
TimerChipType
BatteryComponent
Switch
AcceleromenterType
BatteryTechnology
RadioComponent
Architecture
CoreType
Light
Temperature
Acceleration
ElectricCharge
RadioFrequency
MemoryComponent
ProcessingFrequency
XAxisAcceleration
YAxisAcceleration
ZAxisAcceleration
ElectricCurrent
Voltage
RadioType
RAMMemory
FleshMemory
rdfs:subClassOf
Figure 6 – Classification of components
17 of 20
Cental storage based on
SunSPOT
Table 1 – TypeSN
Table 2 – TypeSNProperties
• general properties of each
hardware platform
• contains the metadata that
describe specific properties
of SN
18 of 20
Conclusion
• We have proposed an ontologically-based
approach for modeling SWSNs
• The topology of the WSN is represented by highlevel ontology, while the semantics of WSN is
represented by appropriate classifications
• The GLOSENT architecture successfully solves the
problem of WSN hardware heterogeneity
19 of 20
Future work
• Dealing with other aspects of
heterogeneity
• Using ontologies for representing Service
• Comand pattern based on ontologies
• Context-sensitive ontologies
20 of 20
Thank you for attention!
Questions?