VIEWS: 6 PAGES: 21 POSTED ON: 1/12/2012
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, 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 WSN segment Application segment MIddleware Service proxy IP App App Proxy OWL IP SUB B Proxy ... Services OWL OWL XML WSN Proxy A1 OWL ... OWL IP SUB C Services ... Services System Image OWL Central Storage WSN Proxy B Zone 1 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.) Figure 3 – WSN • Uniform WSN representation segment relaying on ontology 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 SensorNode Connection hasDestinationNode hasComponent hasComponent Component 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 ID <pi> Long integer Code Variable characters (50) Code Variable characters (50) DESCRIPTION Variable characters (254) DESCRIPTION Variable characters (254) CreatedBy Variable characters (20) LinkDocumentation Variable characters (254) Managed Boolean REL_ParentOfTypeSN LinkDeveloper Variable characters (254) LastReciveUpdate Date ... REL_TypeSNOfProperties REVISION Integer REL_ParentOfTypeSNProperties REL_SensorNodeOf<IdSN>Properties BasestationAdress Variable characters (50) WorkMode Variable characters (20) Lat Long float <IdSN>Properties Lon Long float TypeSNProperties PublicAccess Variable characters (10) ID <pi> Long integer <M> ID <pi> Long integer NameTableProperties Variable characters (100) REVISION Integer <M> Code Variable characters (50) ... VALUE Variable characters (254) <M> DESCRIPTION Variable characters (254) STATE Variable characters (10) <M> ReadOnly Boolean Mandatory Boolean Dynamic table PropType Variable characters (10) Validation Variable characters (254) REL_TypeSNPropertiesOf<IdSN>Properties ... 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 ProcessingComponent SensorComponent SensorID TimerChipType BatteryComponent Switch AcceleromenterType BatteryTechnology RadioComponent Architecture CoreType Light Acceleration Temperature ElectricCharge MemoryComponent ProcessingFrequency RadioFrequency 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 • contains the metadata that hardware platform 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 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?
Pages to are hidden for
"Semantic Web Based Architecture for Managing Hardware "Please download to view full document