Date post: | 15-Jan-2016 |
Category: |
Documents |
Upload: | rhoda-caldwell |
View: | 214 times |
Download: | 0 times |
Semantic Web Based Architecture for Managing Hardware
Heterogeneity in Wireless Sensor Network
Authors:Sinisa Nikolić, MScValentin Penca, MScMilan Segedinac, MScProf. Zora Konjović, PhD
UNIVERSITY OF NOVI SADFACULTY OF TEHNICAL SCIENCESSERBIA
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, battery-
powered, 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
Figure 1 – The GLOSENT architecture
OWL
...
Zone 1
...
...
Zone 2
...
OWL
OWL
OWL
OWL
OWL
OWL
WSN segment Application segmentMIddleware
WSN Proxy A2
WSN Proxy A1
WSN Proxy B
XML
OWLServices
Services
Services
Services
Service proxy App ProxyIP App Proxy
System Image
Central Storage
Metadata
Readings
Roles
IP SUB A UserX
IP SUB B
IP SUB C
OWL
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 segment10 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
Figure 4 – WSN ontology
hasSourceNode
hasDestinationNode
hasComponenthasComponent
hasMeasureUnit
hasRevision
SensorNode Connection
Component MeasureUnit
Revision
14 of 20
• Implements the data persistency• Stores the System image data and the
information about Subapplications
Central storage
Dynamic table
REL_TypeOfSensorNode
REL_ParentOfTypeSN
REL_TypeSNOfProperties
REL_ParentOfTypeSNProperties REL_SensorNodeOf<IdSN>Properties
REL_TypeSNPropertiesOf<IdSN>Properties
SensorNode
IDCodeDESCRIPTIONCreatedByManagedLastReciveUpdateREVISIONBasestationAdressWorkModeLatLonPublicAccessNameTableProperties...
<pi> Long integerVariable characters (50)Variable characters (254)Variable characters (20)BooleanDateIntegerVariable characters (50)Variable characters (20)Long floatLong floatVariable characters (10)Variable characters (100)
TypeSN
IDCodeDESCRIPTIONLinkDocumentationLinkDeveloper...
<pi> Long integerVariable characters (50)Variable characters (254)Variable characters (254)Variable characters (254)
TypeSNProperties
IDCodeDESCRIPTIONReadOnlyMandatoryPropTypeValidation...
<pi> Long integerVariable characters (50)Variable characters (254)BooleanBooleanVariable characters (10)Variable characters (254)
<IdSN>Properties
IDREVISIONVALUESTATE
<pi> Long integerIntegerVariable characters (254)Variable characters (10)
<M><M><M><M>
Figure 5 – Central storage
15 of 20
• 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
Case study: Modeling SN in GLOSENT
16 of 20
• Some basic functionalities of SunSPOT device
• Extensible classification
Classification of SunSPOT hardware components
rdfs:subClassOf
Component
SensorIDSensorComponentProcessingComponent
BatteryComponent
RadioComponent
MemoryComponent
BatteryTechnology
ElectricCharge
ElectricCurrent
Voltage
RadioFrequency
RadioType RAMMemory FleshMemory
Architecture
ProcessingFrequency
CoreType
AcceleromenterType
TimerChipType
Light Acceleration
XAxisAcceleration YAxisAcceleration ZAxisAcceleration
Temperature
Switch
Figure 6 – Classification of components
17 of 20
of 20
Cental storage based on SunSPOT
• contains the metadata that describe specific properties of SN
• general properties of each hardware platform
Table 1 – TypeSN
Table 2 – TypeSNProperties
18
Conclusion
• We have proposed an ontologically-based approach for modeling SWSNs
• The topology of the WSN is represented by high-level 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?