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?