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?