Home

PURDUE UNIVERSITY

1. Decentralized Enterprise systems A Multiplatform Wireless Sensor Network Approach EEE WIRELESS COMMUNICATIONS 2007 VOL 14 NUMB 6 pages 57 66 Marin Perianu R S Scholten J Havinga P J Hartel P H Cluster based service discovery for heterogeneous wireless sensor networks INTERNATIONAL JOURNAL OF PARALLEL EMERGENT AND DISTRIBUTED SYSTEMS 2008 VOL 23 NUMBER 4 pages 325 346 Particle Computer http www particle computer de 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 19 Y Gsottberger et al Embedding Low Cost Wireless Sensors into Universal Plug and Play Environments 7st Euro Wksp Wireless Sensor Networks 2004 pp 291 306 V Arnaudov Unified Management of Heterogeneous Sensor Networks In the Atlantis Framework Brown U 2005 P Levis S Madden J Polastre R Szewczyk K Whitehouse A Woo D Gay J Hill M Welsh E Brewer and D Culler TinyOS An Operating system for Wireless Sensor Networks n Ambient Intelligence Springer Verlag 2005 R Tynan D Marsh D Okane and G M P Ohare Agents for Wireless Sensor Network Power Management In Proc of IEEE ICPPW Conf June 2005 N Ramanathan and M Yarvis A Stream oriented Power Management Protocol for Low Duty Cycle Sensor Network Applications in Proc IEEE EMNE I II Workshop May 2005 A Boulis and M B Srivastava Node level Energ
2. Figure 4 4 gives us an example to statement these three options 29 e Saving Power Mode has only one gateway port COMS e Speeding Mode has four gateway ports COM1 COM3 COM5 COM recommend to select all at one time e Saving Power and Speeding Mode has two gateway ports COM3 COMS recommend to select these two at one time No matter how much the gateway ports to select each function has one XML file created by Service Wrapper with the following format in Table 4 1 Table 4 1 General Wrapped XML Format Request XML lt gateways gt Format lt gateway gt lt device gt COM1 lt device gt lt gateway gt lt gateway gt lt device gt COMi lt device gt lt gateway gt lt gateways gt After interpreted by Service Proxy output the number of target command string is same as the number of gateways described in XML file Table 4 4 in section 4 4 describes the Gateway Monitoring Service Configuration XML file design which provides a XML template of multi WSN platforms with multi available specific gateway communication Ports under above three different modes displaying the system design flexible and scalable 30 4 3 Access Adaption 4 3 1 Unified Gateway Access Technology H WSNMS provides a Unified Interface in the Unified Gateway Layer completing a unified accessing of one or more gateways Owning to the diversity of senor network services provided by various gateways and the variety
3. e Communicate with mote wireless e Send NesC file to mote wireless e Collect mote s data Note e MIB520 Programming board o Upload NesC file to mote wire e MIB520 Mote Base Station o Communicate with mote wireless o Send NesC file to mote wireless o Collect mote s data e MIB520 Mote PC Server o Store data to database Figure 5 1 Mote Hardware The Table 5 1 shows the information of some Sensor boards and motes 43 44 Table 5 1 Sensor Boards and Motes Part name supported MICA MTS300CB MICA2 MICA MTS310CB MICA2 MICA l accelerometer and 2 axis magnetometer MTS400CA IRIS MICAz Ambient light relative humidity temperature 2 MTS400CB MICA2 axis accelerometer and barometric pressure MTS400CC MTS420CA IRIS MICAz Same as MTS400CA plus a GPS module MTS420CB MICA2 MTS420CC MTS510CA MICA2DOT Light microphone and 2 axis accelerometer MDA100CB MICA2 MICA2 interface for external sensors MICA2 MDA500CA MICA2DOT Prototyping area 45 5 2 Software Platform Figure 5 2 shows us the Three tier software architecture instantiated based on Crossbow XServe Client Tier ee 5 O i Figure 5 2 Three tier architecture instantiation based on XServe H WSNMS Software Platform Deployment is composed of the two distinct software layers Client layer and Gateway layer In above three tier architecture the motes tier belongs to the hardware content we have introduced in section 5 1 In the follo
4. method 66 Data Collection Request XML File and Mapped Result Table 5 5 Data Collection Request XML File and Mapped Command String Data Collection Request XML File Request lt xml version 1 0 encoding UTF 8 gt Node lt Datacollreq gt XML lt gateways gt Format lt gateway gt lt gatewayname gt XServe lt gatewayname gt lt gatewayid gt 05 lt gatewayid gt lt servicelD gt 105100 lt servicelD gt lt device gt COM5 lt device gt lt interfaceboard gt MIB520 lt interfaceboard gt lt baudrate gt 57600 lt baudrate gt lt dbinfor gt lt dbserver gt 149 166 32 252 lt dbserver gt lt dbport gt 5432 lt dbport gt lt dbname gt IDAM lt dbname gt lt dbuser gt tele lt dbuser gt lt dbpasswd gt 12345678 lt dbpasswd gt lt databaseparsed gt l lt databaseparsed gt lt xmlfile gt XmlStream xml lt xmifile gt lt xmlp gt lt xmlp gt lt xmlport gt 9005 lt xmlport gt lt dbinfor gt lt gateway gt lt gateway gt lt gateway gt lt gateways gt lt Dataconnreg gt Mapped xserve s COM5 b 57600 dbserver 149 166 32 252 Target dbport 5432 dbname IDAM dbuser tele Command xmlfile XmIStream xml xmlp xmlport 9005 String This is a General and Extendable file Example Available Command parameters for XServer Refer XServe Users Manual 7 in which there is the detail introduction about various XCommand Arguments main parameters xserve s b dbserver dbport db
5. 3 1 H WSNMS System Architecture rrrarrrarrnnrrnnrrnrrvanrnnrrnrrranrnannnannnnnn 9 Figure 3 2 H WSNMS with Virtual Command Set rrrannnnnnnnrnnnenarenannnannnnrnnnnnnn 11 Figure 3 3 Management Service and Application Layer cccccceeeseeeeeeeees 13 Figure 3 4 Unified Gateway Layer rrrnrnnnrnnnnnnrvnnrvanenannnannnnnnnnrnnnenanrnannnnnnnnrnnnennn 17 Figure 3 5 General control and status information flow for Generic Functions 22 Figure 4 1 H WSNMS System Logic Architecture rrrrrnnrrnarerarrrarrrnnnnarnnnnnn 23 Figure 4 2 Virtual Command Set Mapping Module VCSMM rareranrnnrnnnrnnnrnnn 26 Figure 4 3 VCSMM Mapping FIOW ccccccceceeeeeeceece cece eeseeeeeeeeeeeeeesaeeseeeaes 2 Figure 4 4 VCSMM Application ccccccecceecseeceeeeeeceeeeeeeseceeeseeeeeseeeeeeteeeeeees 28 Figure 4 5 Comparison of Service Access Modes ccccccseeeeeeeeeeeeeeeeeeeeaes 30 Figure 4 6 H WSNMS Software Design rrrnnrrnarenarenannrarnnernnnrnnnenannnannnennnsennn 34 PIQUE 51 MOL AnOWAN G sva 43 Figure 5 2 Three tier architecture instantiation based on XServe nrrrarrvarenen 45 Figure 5 3 Gateway Middleware XServe ccccccceecceecceeeceeeseeeseeeeeeeeeeseeseeeaes 46 Figure 5 4 User Profile of H WSNMS rrrnrnnnrnnrrnanenannnannnnnnnnrnnnenannnannnnnnnnnnnnennn 49 Figure 5 5 Monitoring Command Logical FIOW cccceceseeeeeeeeeeeeeeeeseeenes 50 IQUE
6. 3 describes Mote Data Collection Query Service information including sensor location sensor status sensor type sampling rate collection rate and so on the Table 4 4 describes available specific communication port for some certain WSN platform under three different Monitoring modes discussed in section 4 2 3 These XML files can be extended according to system sensor data management requirement This design is very flexible based on which the future system service developers can create new services 39 Table 4 4 Data Collection Service Configuration XML Template File Function Data Collection Service Configuration XML File Config lt xml version 1 0 gt XML lt sensorNet gt Format lt Basicinformation gt lt state gt Indiana lt state gt lt county gt Indiana1 lt county gt lt siteName gt Y_Indianapolis lt siteName gt lt NetType gt Other lt NetType gt lt OriginalPoint Longitude 86 Latitude 39 gt lt BasicInformation gt lt Scope gt lt North Longitude 86 Latitude 39 gt lt South Longitude 86 Latitude 38 gt lt East Longitude 87 Latitude 38 gt lt West Longitude 87 Latitude 39 gt lt Scope gt lt SensorNodes gt lt SensorNode gt lt Nodeld gt 1465 lt Nodeld gt lt NodeLocation x coordinate 1 y coordinate 1 gt lt sensorT ype gt model1 lt sensorT ype gt lt sensorstatus gt work lt sensorStatus gt lt canMeasure gt lt Parameter gt lt BaseTime gt 00 00 00 lt
7. 4 2 describes the wrapping procedure of Virtual Commands VC1 VC2 VCn formatted by Service Wrapper into VCAS XML file The right picture in Figure 4 2 illustrates us the 21 parsing procedure of VCAS interpreted by Service Proxy into the scoped target concepts TC1 TC2 TCn which can indentified and interpreted by heterogeneous WSN gateways Figure 4 3 shows us the VCSMM mapping flow in the red break line In some sense the VCSMM is a XML file Wrapping and Parsing Model from Virtual Command to Target Command to achieve multiple management functions accessing multiple WSN gateways which is a kind of multi to one to multi Process Mapped Target Commands Gateway EE Parsers Real World Commands Figure 4 3 VCSMM Mapping Flow 4 2 3 VCSMM Application Case Discussion During the application of VCSMM considering providing Users a more friendly and humanized management and maintenance of WSNs H WSNMS system gives user several options to select e Saving Power Mode e Speeding Mode e Saving Power and Speeding Mode Usually when monitoring WSNs we should consider the above three situations for some certain type WSN platform it is possible to use multiple gateways to cover all motes for example the Speeding Mode in Figure 4 4 it will give the multiple options COM1 COM3 COM5 COM to select every COMn stands for a Wireless Sensor Network the purpose of this Mode is to quickly cover all possible motes
8. 5 60 MONTONG Yasser area needed E 52 Figure 5 7 Demo of Monitoring rranrnannnnnnnnrnnnrvanrnannnannnnnnnnrnanenannnannnannnnnnnnennn 53 Figure 5 8 Configuration Command Logical Flow cccccceeceeeeeeeeseeeneeeees 54 FOUSS Ge 11002 10 1 Uie bbacdanaiacieeeeecueeeceraeehe 58 Figure Page Figure 5 10 Demo of Get Config rarrrarrnnrnnnrvnrrvanenanrvannnnrnnnrnanenannnannnannnnnnnnennn 58 Figure 5 11 Reprogram Command Logical FIOW ccccecceeeeeeeeeeeeeeeeeeeees 59 FOUG S 12 RENTEN Vlas 63 FIAUS 513 DEMO Ol QUEI soursias ea R eee 63 Figure 5 14 Data Collection Command Logical Flow rrrarrrarnnnrnnnrnnrrvanernnnnnn 64 Figure 5 19 Data Collection UI sssini a E EE 68 Figure 5 16 Demo of Data Collection rrrurnnrrrarenarerarnnarnnernnnenanerannnannnannnnennn 68 Figure 5 17 Demo of New Data Collection rrarrnarrnnnrnnrnnnrvanevannvannnannnnrnnnnnnn 69 Figure 5 18 XServe Command Flow Illustration 2 orororrrrerrnrrnnrrannnrnnnnnr 70 Figure 5 19 XServe Configuration Command Extension cccccceeeeeeeeeeeees 71 Appendix Figure Figure E 1 the Whole Design of H WSNMS rrrrrorerarerarnnarnnernnnrnnnenannrannnernnennnn 88 ABBREVIATIONS ABBREVIATIONS DESCRIPTION GW Gateway GWS Gateway Set H WSNMS Heterogeneous Wireless Sensor Networks Management System MR Metadata Repository MSA Management Service and Application OTAP
9. BaseTime gt lt SampleRate gt 5000 lt SampleRate gt lt CollRate gt lt CollRate gt lt Parameter gt lt canMeasure gt lt SensorNode gt lt SensorNode gt lt SensorNode gt lt SensorNodes gt lt sensorNet gt Note __ This is a General and Extendable file 40 Table 4 5 Monitoring Service Configuration XML Template File Function Monitoring Service Configuration XML File Config lt xml version 1 0 encoding UTF 8 gt XML lt MonitoringServiceConfig gt Format lt Platforms gt lt Platform gt lt PlatformName gt MoteWorks lt PlatformName gt lt GatewayName gt XServe lt GatewayName gt lt Modes gt lt Mode gt Power lt Mode gt lt AvailablePort gt COM5 lt AvailablePort gt lt Mode gt Speed lt Mode gt lt AvailablePort gt COM1 COM3 COM5 COM7 lt AvailablePort gt lt Mode gt PowerSpeed lt Mode gt lt AvailablePort gt COM3 COM5 lt AvailablePort gt lt Modes gt lt Platform gt lt Platform gt lt PlatformName gt Praticle lt PlatformName gt lt GatewayName gt xxxx lt GatewayName gt lt Modes gt lt Mode gt Power lt Mode gt lt AvailablePort gt xxxx lt AvailablePort gt lt Mode gt Speed lt Mode gt lt AvailablePort gt xxxx XXXX XXXX XXXX lt AvailablePort gt lt Mode gt PowerSpeed lt Mode gt lt AvailablePort gt xxx xxx lt AvailablePort gt lt Modes gt lt Platform gt lt Platform gt lt Platform gt lt Platforms gt lt
10. Collection Command Handler Figure 5 18 XServe Command Flow Illustration 2 71 Sensor Network Management System Configuration Mote Configuration ve Set GroupID GroupID Smit Get Config NoteD oo gere S Need Set Collection Rate Data Collection Set Sampling Rat e mm in an Help Network Power Management Sesle Noep Set Reset Noep Gateway ShutDown ShutDown Figure 5 19 XServe Configuration Command Extension 12 CHAPTER 6 FUTURE WORK We provide a scheme to manage sensor networks using XML schema Database technologies and Socket Communication technology The fundamental goal of the scheme is to be able to describe sensors in a simple compact manner while still having the ability to represent essential details such as the general service functions VCS the type of sensor platforms that can be provided the various parameters and application interfaces of specific gateway middlewares that are available in WSNs Based on these technologies we present a three layer framework H WSNMS that provides the basic capabilities for locating managing and querying the heterogeneous Wireless Sensor Networks at the same time XServe command extension over existing command services has finished in this system Consequently the design and implementation of H WVSNMS is not only a challenge but also a chance for web based heterogeneous Wireless Sensor Networks management system The und
11. F Akyildiz W Su Y Sankarasubramaniam and E Cayirci Wireless sensor networks a survey Computer Networks 38 4 393 422 March 2002 T Camp J Boleng and V Davies A survey of mobility models for ad hoc network research Wireless Communications and Mobile Computing WCMC Special issue on Mobile Ad Hoc Networking Research Trends and Applications 2 5 483 502 2002 N Ramanathan E Kohler and D Estrin Towards a Debugging System for Sensor Networks nternational Journal for Network Management vol 15 no 4 2005 pp 223 234 S Bhatti J Carlson H Dai J Deng J Rose A Sheth B Shucker C Gruenwald A Torgerson R Han Mantis OS An Embedded Multithreaded Operating System for Wireless Micro Sensor Platforms ACM Kluwer Mobile Networks amp Applications Special Issue on Wireless Sensor Networks vol 10 no 4 Aug 2005 D Gay P Levis R V Behren M Welsh E Brewer D Culler The NesC Language A Holistic Approach to Networked Embedded Systems n Proc ACM SIGPLAN Conf on Programming Language Design and Implementation June 2003 Donald Brutzman Michael Zyda J Mark Pullen and Katherine L Morse Extensible Modeling and Simulation Framework XMSF Challenges for Web Based Modeling and Simulation Findings and Recommendations Report of the XMSF Technical Challenges Workshop and Strategic Opportunities Symposium October 2002 APPENDICES Appendix A Table A 1 Parameters
12. Management Request 6 Send WSN Data Cdllection Virtual Command 7 Target Command 8 11 Return unsuccessfully 9 No Command executed Command valid information 10 Respons unsuccessfully 9 Yes Command executed 10 Store Sensor Data into DB successfully 11 DB Query Request 13 Display Retrieved Data 12 Return Data Figure 5 14 Data Collection Command Logical Flow Function user retrieves the wireless sensor data from H WSNMS wireless sensor network data source in its own DB Flow Description Users send a WSN Data Collection request system will visit the H WSNMS DB to check whether the retrieved data existed or not if yes display the result to users if no user send a send a WSN Data Collection function request again which will be wrapped to the virtual command XML package then is interpreted and mapped to the target command string sent to XServe then 65 XServe judges whether the target command string is valid or not If not return the information about unavailable data to users if yes the data coming from motes in WSNs synchronizes into H WSNMS DB then response and display the data to users according to users query time requirement i e Under the satisfaction of condition the new data will be stored into DB at the same time return a Data Notification After receives the Data Notification the system will re send DB query request Thus users retrieve the data with on demand
13. MonitoringServiceConfig gt Note This is a General and Extendable file 4 4 4 Data Structure and Definition Considering that some certain function such as Data Collection function need to synchronize the wireless sensor data and Configuration function maybe update platform or WSN gateway status information these dynamical data and status information management should stored in the system own database The HWSNMS DB is responsible for storing and maintaining these 41 data and configuration information which is designed and implemented through using the PostgreSQL database technology Some Datatables are described in Appendix D 42 CHAPTER 5 H WSNMS CASE STUDY b 1 Experiment Hardware In this chapter we will discuss the H WSNMS XServe 7 Instantiation based on HIDE system in detail Before the discussion of H WSNMS Application design we should introduce the experiment environment Hardware is composed of three parts Mote Sensor board and Programming board as shown in the Figure 5 1 Mote Type Micaz e Processor ATmega 128L e Freq 2400 MHz to 2483 5 MHz e Range Outdoor indoor 75 m to 100 m 20 m to 30 m e Onboard Sensor extend board None Yes Sensor Board MTS310 e Light Temperature Microphone Buzzer 2 axis Accelerometer and 2 axis Magnetometer Sensor e Compatible with IRIS MICAz MICA2 Processor Radio Boards Gateways MIB520 Mote e Programming board MIB520 Upload NesC file to mote wire
14. OF TABLES Table Page Table 3 1 Virtual Command Category and Specification of VCS r rrrerrnrenerr 15 Table 4 1 General Wrapped XML Format ccccecceccsecseeteeeeeeeeeeeeeeeeteeneees 29 Table 4 2 Wrapped XML Template File and Mapped Command String 36 Table 4 3 SPECNGAUON OF COAG eicisinisioreiciaieveielabeiersiavereialareiotelsdoteiebebenaelaieieialss 37 Table 4 4 Data Collection Service Configuration XML Template File 39 Table 4 5 Monitoring Service Configuration XML Template File 0 40 Table 5 1 Sensor Boards and Motes Luvsssesssesseesne eee dedd 44 Table 5 2 Monitoring Request XML File and Mapped Command String 51 Table 5 3 Configuration Request XML File and Mapped Command String 56 Table 5 4 Reprogram Request XML File and Mapped Command String G1 Table 5 5 Data Collection Request XML File and Mapped Command String 66 Appendix Table Table A 1 Parameters Definition cccccccceccceeeceecseeseeeceeceeeceeeeeesaeeseeeseeees IT Table A 2 Command Category and Specification of VCS rrrarrrarerarrrarerarnnern 78 Table B 1 XServe Command Line Parameters ccccccccececeeeeeeeeeeeeeeseeeseees 19 Table B 2 XServe Configuration Command Line Parameters 0000800e 80 Table B 3 XServeTerm Line Parameters rrrrrnnrrnarerarevanrrarnnrnnnrnaneranennnnnnnn 80 Table B 4 XServeTerm Available Param
15. Over the air Programming SC Service Component SOA Service Oriented Architecture TC Target Command TCS Target Command Set UG Unified Gateway UGA Unified Gateway Access VC Virtual Command VCA Virtual Command Attributes VCAS VCC VCS VCSMM WSN WSNs XML Virtual Command Attributes Set Virtual Command Category Virtual Command Set Virtual Command Set Mapping Model Wireless Sensor Network Wireless Sensor Networks Extensible Mark up Language ABSTRACT XI Yu Qun M S Purdue University August 2010 Design and Implementation of Web based Data and Network Management System for Heterogeneous Wireless Sensor Networks Major Professor Yao Liang Today Wireless Sensor Networks WSNs are forming an exciting new are to have dramatic impacts on science and engineering innovations New WSN based technologies such as body sensor networks in medical and health care and environmental monitoring sensor networks are emerging Sensor networks are quickly becoming a flexible inexpensive and reliable platform to provide solutions for a wide variety of applications in real world settings The increase in the proliferation of sensor networks has paralleled the use of more heterogeneous systems in deployment In this thesis our work attempts to develop a new network management and data collection framework for heterogeneous wireless sensor networks called as Heterogeneous Wireless sensor Networks Management System H
16. Strinc This is a General and Extendable file Example Available Command Parameters for XServe Refer XServe Users Manual 7 in which there is the detail introduction about various XCommand Arguments Reconfiguration includes following xcommands H ReConfig GID set default group lt group id gt H ReConfig GetlD get config lt destination address gt H ReConfig SetlD set nodeid lt destination address gt lt new node id gt H ReConfig SpRate set rate lt destination address gt lt new 57 rate gt H_ReConfig CRate set collection rate lt destination address gt lt new size gt H ReConfig ECollect set manual collection lt destination address gt lt Flag gt Power Management includes following xcommands H PM WAKEUP wake lt destination address gt H PM SLEEP sleep lt destination address gt H PM RESET reset lt destination address gt H PM SHUTDOWN xserve shutdown Function Information Description Configuration Service Set NodelD based on XServe provided by MoteWorks platform with communication port COM Service Code 1 05 1 22 1 MoteWorks PlatformID 05 Device GatwaylD COM port COM5 1 Gateway Code of XServe 22 H Config Reconfig GetlD Set NodelD Service VC Code Socket Port Code 1 1 20 1 Platform Code or PlatformID MoteWorks produced by Crossbow 1 Gateway Code of XServe 20 Configuration Service VCS Code 1120 Socket Port 1120Req xml Configuration Function XML file name Note the codes rule and def
17. Virtual Command set VCS into a Target Command s for WSN gateway s In this layer the Service Proxy component provides a mapping function between service Components in MSA layer and WSN gateway Command Service s displaying the multiple management functions accessing multiple WSN applications Besides the two control components Gateway Access component and Communication Mechanism component build the communication bridge between MSA layer and Mote layer responsible for transmitting the Target Command s to WSN gateways e Mote Layer This layer consists of in general multiple heterogeneous WSN gateways associated with their preliminary management Command Services During the above discussion H WSNMS architecture an important concept should be introduced here Virtual Commands Set VCS By VCS each management service component is deemed to be realized by a Virtual Command or a sequence of Virtual Commands from the VCS and each individual Virtual Command could be either partially or completely mapped to a combination of some existing Command Services under the given WSN gateway with its preliminary management Command Services as shown by Figure 3 2 11 MSA Layer with components UG Layer with VCS Command Service 1 uel Mote Layer consisted Ervice with n Command services Command Service n Figure 3 2 H WSNMS with Virtual Command Set In Figure 3 2 each plane presents a concrete WSN gateway Command Service t
18. components can be mapped to the Target Command already provided by XServe 5 3 Main Functions Overview This section will discuss the main functions of H WSNMS based on CrossBow XServe In this system there are several main functions e Monitoring supervises the status of Wireless Sensor Networks e Configuration completes Mesh Motes Configurations with XCommands e Reprogram uploads the OTAP program to the motes e Data Collection retrieves and displays the wireless sensor data from HIDE own sensor data resource The general control and status information flow in H WSNMS system has been illustrated in Figure 3 2 the following sections we will one by one discuss the control and status information of functions such as Monitoring Reconfiguration and Reprogram and so on The screenshot shown in the Figure 5 4 is system user profile of H WSNMS WSN Management System which provides a series of functions such as Monitoring Configuration Reprogram and Data Collection and so on Menu List Platform Management 49 Welcome to H WSNMS System H WSNMS System Heterogeneous Wirless Sensor Networks Management System H WSNMS Monitoring Supervise the status of Wireless Sensor Networks H WSNMS Configuration Complete Mesh Motes Configurations with Command H WSNMS Repregram Upload the OTAP program to the motes H WSNMS Data Collection Retrieve and displays the wireless sensor data from HWSNMS wireless sensor data resourc
19. gt xserve lt interfaceboard gt lt xotap gt xotap exe lt xotap gt lt commands gt lt ip port gt lt cmd gt sf lt cmd gt lt ip gt localhost lt ip gt lt port gt 9001 lt port gt lt ip port gt lt image_number gt lt cmd gt i lt cmd gt lt number gt 2 lt number gt lt image number gt lt boot gt lt cmd gt p lt cmd gt lt image number gt lt image number gt lt boot gt lt query gt lt cmd gt lt cmd gt lt query gt lt load gt lt cmd gt lt cmd gt lt file gt C main exe ihex lt file gt lt load gt lt threshold gt lt cmd gt v lt cmd gt lt vantage gt 2 7 lt vantage gt lt threshold gt lt commands gt lt modes gt lt mode gt 1458 lt mote gt lt modes gt lt gateway gt lt gateway gt 62 lt gateway gt lt gateways gt lt Reprogramreg gt e g C Crossbow cygwin opt MoteWorks tools xotap bin cygwin x86 xotap exe 2 p v 2 7 sf localhost 9001 1458 This is a General and Extendable file Available Command Parameters for XServe Refer XMesh Users Manual 8 in which there is the detail introduction about various XOTAP Command Arguments f lt image_ file gt Download the file i lt image number gt Image number q Query the Mote status v lt threshold gt Download if the voltage is above the threshold default 2 7v p lt image number gt Boot the image number Sf lt ip port gt XServe host port default to localhost 9001 c
20. in these four Wireless Sensor Networks if user can select all Wireless Sensor Networks But in this mode plenty of power in WSNs 28 would be wasted and even lost without any benefit although this way can improve and increase the data link speed to get more information such as the sampling data and other configuration and platform status than other modes there exists a potential flaw power wastage On the other hand if just considering power saving only one WSN is selected like the Saving mode COM5 shown in Figure 4 4 the limited motes covered by one WSN can be visited although this mode can save the power of this WSN it cannot guarantee to access all possible motes so its limitation is obvious Based on the analysis on the previous two modes the third mode Saving Power and Speeding Mode becomes a comprehension option for users which provides maybe a better not the best option COM3 and COMS as shown in the picture No matter which method is best option it depends on user requirement so system provides monitoring mode configuration to satisfy users The mode configuration is described by XML file The available WSN gateway power situation and cover performance should be done some statistics and represented in metadata file 1 Monitoring VC Saving Power COMS Mode COM1 COM3 C Speeding 4 Monitoring VCs Mods COM5 COM7 Saving Power COM3 and Speeding Mode COM5 Figure 4 4 VCSMM Application 2 Monitoring VCs
21. lt COM port gt Serial port if connected directly eg c COM1 motelD motelD List the Motes to download or check status Function Information Description Reprogram Service BOOT based on XServe provided by MoteWorks platform with communication port COM5 Service Code 1 05 1 61 1 MoteWorks PlatformID 05 Device GatwaylD COM port COM5 1 Gateway Code of XServe 61 H Repro BOOT Boot Service VC Code Socket Port Code 1 1 60 1 Platform Code or PlatformID MoteWorks produced by Crossbow 1 Gateway Code of XServe 60 Reprogram Service VCS Code 1160 Socket Port 1160Req xml Reprogram Function XML file name Note the code rules and definitions refer to the Appendix A C Demo Menu List Options cmd query sf localhost 9001 group id 129 debug 1 63 Sensor Network Management System Reprogram Mote Reprogram Send To Nodes 0 1 All Nodes OTAP Query Boot Image Download Image Voltage Image File Figure 5 12 Reprogram Ul html report file xotap html motes 1458 Figure 5 13 Demo of Query 64 5 3 4 Data Collection Function and Demo Figure 5 14 shows us the Logical Flow of WSN Data Collection Function Wireless Sensor Network Base Station LLL User MAS UG WSN GateWay XServe 1 WSN Data Collection Request 2 DB Query Request 3 5 Display Retrieved Data 4 Yes Response Data i Data valid 4 No Data not exist in DB 5 WSN
22. management service components the arguments of which i e User request which is called as Virtual Command in this system are wrapped into Metadata XML file format stored in service Repository 14 The main service components involve Monitoring component Configuration component Reprogram component Data Collection components and so on The detail design and implementation will be introduced in Chapter 5 3 2 2 MSA Metadata Repository MSA Metadata Repository MSA MR component is a DB of available services configuration such as the VCS configuration the target gateway service configuration and XML documents containing the service description and so on It is composed of the following parts e VCS Configuration A available file to define Virtual Command Category VCC which has two aims one is to more conveniently describe service components from MSA layer the other one is to help to automatically create socket communication port for management services with same type i e the same type management services with the same WSN platform and same WSN gateway will share a same socket communication port The code of port is composed of the code of VCC the code of WSN platform and the code of WSN gateway The latter two codes are described and defined in the Metadata Repository in UG layer The Table 3 1 shows us the definition of VCC and Specification of VCS The detail code of VCC refer the Appendix A which includes more details
23. of accessing protocol standard provided by different sensor networks different type services have their own functions such as monitoring reconfiguration reprogram data collection and so on Services Interface Unified Access Technology Servicel Servicel VCI VCI ON Service2 Service2 VC2 VC2 Adaption Servicen Servicen VCn VCn Access Mode A Access Mode B Figure 4 5 Comparison of Service Access Modes Figure 4 5 displays the Traditional Service Access Mode and Unified Access Mode Traditional Service Access Mode Access Mode A make the interface between Service Platform and WSN gateways over many which obviously is not good for service extension and update Otherwise Unified Access Mode Access 31 Mode B can overcome the above defect and undoubtedly bring the following advantages to Service development We call this Unified Access Mode as Unified Gateway Interface which is unique channel between the Service Management Platform and the Wireless Sensor Networks being responsible for interoperating between different service and different service gateway and implementing the Adaptation of multi service and multi gateway UG provides a means of real time two way communication between two data terminal installations after the mapped target command outputs from Service Proxy the UG MR component UG Access component and Communication Mechanism component work together to complete the processing of the tar
24. the discussion above H WSNMS presents a three layer architecture that accommodates different sensor platforms and exposes their functionality in a uniform way to the business application e Management Service and Application layer e Unified Gateway or Platform Abstraction layer e Mote or Device layer These three layers are illustrated in Figure 3 1 and discussed in detail throughout the following subsections WSNs Service and Application Users lem oa Service Components cx O A os Sc Q Service Reposito ES Oo DE Ea d S gt UG Metadata Gateway Service a Repository Access Proxy gt D 27 DN Mo WO amp amp Jb Jb go Communication Mechanism ES Cc gt 5 ctoway2 Guo gt 2 O gt Wireless Sensor Networks Table H WSNMS DB Figure 3 1 H WSNMS System Architecture From Figure 3 1 we can see H WSNMS System Architecture contains three layers e Management Service and Application MSA Layer This layer is the composition of different WSN management components each of which is tailored for application requirements and independently 10 performs some specific functions that are defined by Service and Application Client and are described in Service Repository e Unified Gateway UG Layer This layer is the core of our proposed H WSNMS architecture that is responsible for interpreting each Virtual Command from
25. 0 lt interfaceboard gt lt baudrate gt 57600 lt baudrate gt lt gateway gt lt gateway gt lt gateway gt lt gateways gt lt Monitoingreq gt Mapped e g Target XServe device COM5 baudrate 57600 Command Strinc This is a General and Extendable file Example Available Command Parameters for XServe Refer XServe Users Manual 7 in which there is the detail introduction about various Command Arguments XServe device baudrate Function Information Description Monitoring Service Monitoring based on XServe provided by MoteWorks platform with communication port COM5 Service Code 1 05 1 10 1 MoteWorks PlatformID 05 Device GatwaylD COM port COM5 1 Gateway Code of XServe 10 H Monitoring Monitoring Service VC Code 52 Socket Port Code 1 1 10 1 Platform Code or PlatformID MoteWorks produced by Crossbow 1 Gateway Code of XServe 00 Monitoring Service VCS Code 1110 Socket Port 1110Req xml Monitoring Function XML template file name Note the code rules and definitions refer to the Appendix A C Demo Welcome to HWSNMS Management Platform Monitoring Wireless Sensor Platform Information Menu List Please Select Wireless Sensor Platform MoteW orks v Configuration Reprogram Please Select Interface Board Data Collection MIB510 vi System Test Please Select Baud Rate Platform Management 57600 vi Please Select Serial Port Power S
26. 010 07 15 23 38 42 MTS310 sensor data converted to engineering units 15 health node id 1458 parent 0 16 battery 2926 mv 17 temperature 273 149994 degC 18 light 1055 ADC mv 19 mic 386 ADC counts 20 AccelxX 780 000000 milliG ccelY 460 000000 milliG 21 MagX 45 915646 mgauss MagY 30 655447 mgauss 22 2010 07 15 23 38 44 7E 00 FD 7D 02 9B 04 7 23 2010 07 15 23 38 44 amtype Oxfd 24 2010 07 15 23 38 44 amtype 253 Figure 5 7 Demo of Monitoring 54 5 3 2 Configuration Function and Demo Figure 5 8 shows us the Logical Flow of Configuration Function Wireless Sensor Network Base Station L User MAS UG WSN GateWay XServe 1 WSN Management Request 2 Send WSN Virtual Configuration Command 3 Target Command 4 Command valid 7 Return unsuccessfully 5 No Command executed grm 6 Response unsuccessfully 7 Return Ee 5 Yes Command executed information 6 Response successfully 6 Modify Database Information Modify Sensor running information Figure 5 8 Configuration Command Logical Flow Function User can send and receive XCommand to complete the configuration using XServeTerm Flow Description When Users enter WSN Management system Users send one Configuration function request which will be wrapped to the virtual command XML package then is interpreted and mapped to the target command string XCommand string and is sent to XServe then XServe ju
27. 15 Table 3 1 Virtual Command Category and Specification of VCS vwe command Function Data H DataColl Data Collection collection VCS H DataColl VCS sensor data H Monitoring Configuration H Config Reconfig SpRate SET RATE Set new VCS Sampling H_ Config Rate H Config Reconfig NID SET_NODEID Assign Node ID H Config Reconfig GID SET_GROUP Assign a Node to new group H Config Reconfig CRate Set collection rate H Config Reconfig ECollect Immediately perform a data collection from WSN and store it to DB ape a ested H Config PM RESET RESET MN SS H Config PM SLEEP SLEEP H Config PM WAKEUP WAKEUP bee ee Reprogram H_Repro_Boot as Set H_Repro_Query a H_Repro H Repro Load a e Gateway Service Configuration A series of available files with format xml or txt configuring various WSN gateway status information spatial information the available 16 gateway communication port information and gateway middleware parameters information and so on The detail design of XML template is shown as Table 4 3 Table 4 4 in Chapter 4 e Service Wrapper It is a XML Wrapper responsible for describing service components in MSA layer i e wrapping VC s corresponding to these service components with Metadata XML file format The detail design of XML template is shown as Table 4 2 in Chapter 4 These XML files in Service Wrapper usually are sent to Service Proxy in UG layer to be mapped and interpreted in
28. 25 272 1458 0 416 0 371 394 409 318 229 2010 07 08 23 06 29 632 11458 0 1416 0 371 394 409 318 229 2010 07 08 23 06 34 522 1458 0 416 0 371 394 409 318 229 2010 07 08 23 06 39 413 1458 0 416 0 371 1394 409 1318 229 Data Collection 2010 07 09 00 38 10 944 1458 0 420 lo 1370 405 425 315 1227 2010 07 09 00 38 15 678 1458 0 420 0 371 405 425 314 1227 2010 07 09 00 38 20 569 1458 lo 421 0 371 404 425 314 1227 2010 07 09 00 38 25 444 1458 0 420 0 371 404 425 314 1227 2010 07 09 00 38 30 335 1458 0 420 0 370 403 424 314 1227 2010 07 09 01 06 49 741 11458 0 424 0 370 395 418 307 225 2010 07 09 01 06 54 475 11458 0 424 0 370 396 418 308 225 2010 07 09 01 06 59 366 11458 0 424 0 370 396 418 307 225 2010 07 09 01 07 04 241 11458 0 424 0 370 395 418 1307 1225 0 2010 07 09 01 07 09 116 1458 0 424 0 370 395 418 307 225 2010 07 09 01 07 14 007 1458 0 424 0 370 396 418 320 1227 2010 07 09 01 07 18 882 1458 0 424 0 370 396 418 333 1227 2010 07 09 01 07 23 757 11458 0 424 0 370 396 418 315 226 2010 07 09 01 07 28 663 1458 0 424 0 370 396 418 310 1225 2010 07 09 01 07 33 538 1458 0 424 0 370 394 417 309 225 2010 07 09 01 07 38 428 11458 0 424 0 370 1396 418 1309 1225 Figure 5 16 Demo of Data Collection 69 Sensor Network Management System Data Collection Wireless Sensor Platform Data Collection Your Message Received client come in IP 134 68 77 90 1100 Client send is Xserve device COMS baudrate 57600 dbserver localhost dbport
29. 5432 dbname IDAM dbuser tele dbpasswd 12 zom 0 Xserve Data Connection Command C Crossbow cygqwin bin bash login C HUSNMSYxmli HUSNM Commands command txt Data Collection Menu List Data Query Starting 2010 07 15 22 44 37 xdebug could not open log file opt Motellorks tools xserve bin logs xserve log txt No such file or XSERVE 2 0 E Id xserve c v 1 8 2 3 2007 02 02 17 45 01 rkapur Exp Using params db parsed xml parsed server port 9001 Opening serial device dev ttyS4 57600 2010 07 15 22 44 38 Serial Source Msg sync guery INSERT into mts310 results result time nodeid parent voltage temp light accel x accel y mag_x mag_y mic values nor Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel y mag_x mag_y mic values nor Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel y mag_x mag_y mic values nor Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel y mag_x mag_y mic values not Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel_y mag_x mag_y mic values not 2010 07 15 22 44 37 xdebug could not open log file opt Motellorks tools xserve bin logs xserve log txt No such file or XSERVE 2 0 E Id xserve c v 1 8 2 3 2007 02 02 17 45 01 rkapur Exp Using params db parsed xml parsed server port 9001 dp
30. Definition Platform Name Wireless Sensor Platform Name Particle produced by Particle Computer uNode produced by Ambient Systems Sindrion produced by Infineon Technologies MoteWorks produced by CrossBow Roasio KM Be used to describe the command service ServicelD extendable NXXYOO NXXY09 for H DataColl VCS is DataColl VCS NXXY20 re H Config VCS NXXY21 NXXY39 for H Config Reconfig subVCS NXXY40 NXXY59 for H_Config PM subVCS NXXY60 NXXY69 for H Repro VCS NXXY70 for H Others VCS VCS Category H DataColl Data Collection H Monitoring Sernsor and gateway Information Monitoring H Config Sernsor and gateway information configuration H Repro Reprogram SubVCS Category H Config 1 H_Config_Reconfig 2 H Config PM VCS Code RegString XML 1 Stored in Serviced Repository extendable 2 Be parsed to Target Command String to send to Mote layer 3 XML file name based on Socket Port No e g XML file for Data Collection NYOOReq xml Socket IP Socket Server IP address xxx XXX XXX XXX Socket Port PortID NY00 forH DataColl extendable NY10 for H Monitoring NY20 forH Config NY60 for H Repro Tf Table A 2 Command Category and Specification of VCS VCS Category VC Command Function gt H DataColl H DataColl Data connection CO Ls eee ee lee sensor data Sampling Rate H Repro H_Others Le a H Config Reconfig NID SET NODEID Assign Node ID H Config Reconfig GID SET GROUP Assign
31. Graduate School ETD Form 9 Revised 12 07 PURDUE UNIVERSITY GRADUATE SCHOOL Thesis Dissertation Acceptance This is to certify that the thesis dissertation prepared By Qun Yu Entitled Design and Implementation of Web based Data and Network Management System for Heterogeneous Wireless Sensor Networks For the degree of Master of Science Is approved by the final examining committee Yao Liang Chair Xukal Zou Yuni Xia To the best of my knowledge and as understood by the student in the Research Integrity and Copyright Disclaimer Graduate School Form 20 this thesis dissertation adheres to the provisions of Purdue University s Policy on Integrity in Research and the use of copyrighted material Approved by Major Professor s Yao Liang Approvedby ShiaofenFang A July 2010 _ Head of the Graduate Program Date Graduate School Form 20 Revised 1 10 PURDUE UNIVERSITY GRADUATE SCHOOL Research Integrity and Copyright Disclaimer Title of Thesis Dissertation Design and Implementation of Web based Data and Network Management System for Heterogeneous Wireless Sensor Networks For the degree of Master of Science I certify that in the preparation of this thesis I have observed the provisions of Purdue University Teaching Research and Outreach Policy on Research Misconduct VIII 3 1 October 1 2008 Further I certify that this work is free of plagiarism and all materials appearing in this thesis disser
32. J2EE Framework in Web based Management Platform has following features e Portability of Web based component o Over different vendor platform o Over different operational environment o Portability Scalability Reliability e Leveraging existing J2EE programming models for service implementation 35 e Easy to program and deploy o High level Java APIs o Use existing deployment model 4 4 2 System User Interface Design This section is mainly developed with JSP and Java Script technologies There are some demos displayed by an instantiation in the Chapter 5 4 4 3 XML Template and Definition Based on the above the key technologies and core models in this section we will focus on the implementation of the whole system As we know the design and implementation of VCSMM becomes the most important part in H WSNMS system one side the Service Wrapper is responsible for wrapping the virtual commands automatically creating XML template file s based on different Management Service Components another side the Service Proxy is responsible for interpreting the XML file into the target commands The Table 4 2 is an example of wrapped XML template about Virtual Command Set and final Mapped Target Command String This XML template is specific for of Data Connection Function through which system can get the WSN Gateway information that is responsible for receiving the target command s and sending them to Mote layer and Database informat
33. SNMS A Web Based Heterogeneous Wireless Sensor Networks Management System Architecture nbis pp 155 162 2009 International Conference on Network Based Information Systems 2009 Akyildiz and I Kasimoglu Wireless Sensor and Actor Networks Research Challenges Ad Hoc Networks J vol 2 no 4 2004 pp 351 67 MicaZ DataSheet CrossBow Technology Inc Available online http www xbow com Products Product pdf files Wireless pdf MICAZ Da tasheet pdf accessed in March 2009 MoteView User Manual CrossBow Technology Inc Available online at http wWww xbow com Support Support pdf files MoteView Users Manual pdf accessed in March 2009 MoteWorks Getting Started Guide CrossBow Technology Inc Available online at http www xbow com Support Support pdf files MoteWorks Getting Started Guide pdf accessed in March 2009 XServe User Manual CrossBow Technology Inc Available online at http www xbow com Support Support pdf files XServe Users Manual pdf accessed in March 2009 XMesh User Manual CrossBow Technology Inc Available online at http www xbow com Support Support pdf files XMesh Users Manual pdf accessed in March 2009 M Turon Mote View A Sensor Network Monitoring and Management Tool in Proc of IEEE EMNET II Workshop May 2005 pp 11 18 R M Kling Intel Motes Advanced Sensor Network Platforms and Applications EEE MTT S Intl Microwave Symp 2005 Marin Perianu M Meratnia N Havinga
34. TC1 TC2 TCn Gateways For real Gateway objects GW1 GW2 GWm susceptible of being exchanged according to Gateway Configuration information there must be a set GWS of independent objects in the reference WSN platform model such that GWS GW1 GW2 GWm Objects can be added as new gateways join the federation 26 This extended framework advocates the creation of a VCSMM during the implementation of Service function component The main advantage of VCSMM is the creation of a series of information exchange requirements with a specific input output command set and format to which all participating function models have to abide It becomes in fact the common language spoken and understood by all members of a federation In VCSMM models interoperate through the VCSMM Each model understands the language of the VCSMM and can therefore exchange information with any other model A new model joining the federation must only interface with the VCSMM and it automatically interfaces with the rest of the federation TC11 TClt TCm1 TCmt TC21 TC2t TC31 TC3t TC 1 TC t TC41 TC4t TCS1 TC5St Figure 4 2 Virtual Command Set Mapping Module VCSMM In the design of a heterogeneous WSNs management platform the VCSMM reduces the number of total interfaces in a federation of N VC from N interfaces one to one Model in one to one model to 1 interface multi to one to multi Model as in Figure 4 2 VCSMM The left picture in Figure
35. WSNMS which enables to manage and operate various sensor network systems with unified control and management services and interface The H WSNMS framework aims to provide a scheme to manage query and interact with sensor network systems By introducing the concept of Virtual Command Set a series of unified application interfaces and Metadata XML files across multiple WSNs are designed and implement the scalability and flexibility of the management functions for heterogeneous wireless sensor networks which is demonstrated though through a series of web based WSN management Applications such as Monitoring Configuration Reprogram Data a XII Collection and so on The tests and application trials confirm the feasibility of our approach but also still reveal a number of challenges to be taken into account when deploying wireless sensor and actuator networks at industrial sites which will be considered by our future research work CHAPTER 1 INTRODUCTION 1 1 Research Background A wireless sensor network WSN 1 consists of spatially distributed autonomous sensors cooperatively monitor physical or environmental conditions such as temperature sound vibration pressure motion or pollutants The development of wireless sensor networks WSNs was motivated by military applications such as battlefield surveillance They are now used in many industrial and civilian application areas including industrial process monitoring and contr
36. a Node to new group H Config Reconfig CRate NM Set collection rate H Config Reconfig ECollect Immediately perform a data collection from WSN and store it to DB eee ee tee ee H Config PM_RESET RESET 1 o o H Config PM SLEEP SLEEP y H Config PM WAKEUP WAKEUP o FEE EE ee H_Repro Boot PG H_Repro Query y O H Repro Load 1 yo EE EE am 78 79 Appendix B Table B 1 XServe Command Line Parameters Usage xserve lt r a p c xr xp xc dbxmlr xmlp xmlc v alert m gt lt l tablename gt lt dbserver servername gt lt dbport portnum gt lt dbname database name gt lt dbuser username gt lt dbpasswd password gt lt h path hostname portnum config file gt lt m com baud protocol slaveaddress defaultregistervaluesas gt lt xmlfile filename gt lt xmlport portnum gt lt sf hostname port gt lt fsf hostname port gt lt device dev gt lt port num gt lt baud num gt lt platform plt gt lt debug level gt lt configfiles filename filename gt lt loadparsers filename filename gt lt loaddatasinks filename filename gt lt heartbeat lt num missed gt display help help r raw display of tos packets raw a ascii display of tos packets ascii p parsed display of tos packets parsed c converted display of tos packets conveted xr raw tos packets xported to file export raw xp parsed tos packets exported to file export parsed
37. al database allows XServe to store and process sensor and network information Integration with back end monitoring control and management systems delivers the full value of wireless sensor networks to enterprises and makes the connection of the physical world with the internet a reality Gateway Server XServe Remote Access XOtap Mi Database XMesh Modbus Custom Figure 5 3 Gateway Middleware XServe 47 In higher level services for enterprise applications Crossbow XServe can be configured to parsing sensor packets into a series of name values pairs giving richer meaning to the sensor data Crossbow sensor applications allow users to query state variables This feature is called XCommand 7 XServe provides two interfaces for enterprise applications to send commands to the Mote Layer using XCommand Users can send and receive XCommands using XServe Term a terminal command application Applications can send and receive XCommands using an XML RPC interface XCommand and XServe erm are commonly and regularly used in the Management Application Functions such as Monitoring Configuration and Data Connection and so on XServe 8 also implements the Over the air Programming OTAP 8 function which feature allows users to reprogram any Mote within the XMesh 8 network OTAP allows one or more Motes to receive new programming images from XServe via XOtap a server side a
38. and Communication Mechanism to access every wireless sensor network to compete wireless sensor data and network management 3 5 H WSNMS DB H WSNMS Database is a DB of available services storing the updated information from Mote Configuration and the updated Platform status and the motes data that can be retrieved from Wireless Sensor Networks through Date Collection function The PostgreSQL database technology helps us to complete this part 21 3 6 System General Function Logical Flow After introduction of H WSNMS Three layer architecture and the components in each layer we can overview the whole system design like Figure E 1 in Appendix E Shows us Now we give the general control and status information flow for generic functions in H WSNMS system as illustrated in Figure 3 5 At the beginning Users send a request to Function components in the MSA Layer then the requesting information i e Virtual Command s is sent to the UG layer and is wrapped into XML file s as attribute values in the Service Wrapper which is are parsed and interpreted by the Service Proxy into the target command string s identified by WSN gateway s in Mode Layer after its their own interpreter s then the WSN gateway s send the authorized command streams with binary format to the Base Station s which broadcast them into motes in WSNs So far the Requesting processing as the solid line shown has been completed after mote s receives and executes t
39. arsers files default all files are loaded loaddatasinks load only the listed datasinks files default all files are loaded heartbeat turn on the heartbeat monitor and reset after lt num missed gt convZto2 convert incoming network packets from micaZ headers to mica2 headers and vice versa conv2toZ convert incoming network packets from mica2 headers to micaZ headers and vice versa Table B 2 XServe Configuration Command Line Parameters Usage xserve lt r a p c xr xp xc dbxmlr xmlp xmlc v alert m gt device connect to serial device lt default dev ttySO gt baud set serial baud rate lt default 57600 gt device connect to serial device lt default dev ttySO gt Table B 3 XServeTerm Line Parameters XServeTerm Line Parameters Usage xcommand lt gt lt server host port gt lt network xmesh xsensor gt display help help server xserve command port host port network network type default xmesh xmesh xsensor seq starting sequence number default 100 group network group id default 145 81 Table B 4 XServeTerm Available Parameters XServeTerm Available Parameters Available Commands set_timeout lt timeout ms gt set_starting sequence lt sequence number gt set_default_group lt group id gt get_config lt destination address gt set_rate lt destination address gt lt new rate gt set_nodeid lt destination address gt lt new node id gt s
40. asks and applications 1 2 Research Goal In this thesis our main goal is to put forward a Heterogeneous WSNs management system solution scheme and implement it based on a prototype environment This system should have the following features as described e A unique open scalable and flexible WSN Management Comprehensive Application Platform Architecture e A Service Oriented WSN management platform e A scalable Unified Gateway across multiple WSNs In the design of our H WSNMS architecture some key component designs are involved such as Service Mapping design and Unified Gateway Access design In this thesis we adopted the application of the Extensible Mark up Language XML which enables a new level of interoperability for heterogeneous IT systems Using a common reference model improves this process and leads to Virtual Command Set Mapping Model VCSMM Service Mapping The results can be used immediately to configure mediation layers integrating services into an overall service oriented architecture Besides the Unified Gateway Access is designed for integrating various different wireless sensor platforms and accessing the third part gateway interfaces with other standards which is flexible and extendable CHAPTER 2 RELATED WORK 2 1 Current Sensor Network Platforms 2 1 1 MoteWorks Platform Crossbow 4 was one of the first suppliers of the Berkeley style MICA motes 4 which employ the TinyOS operating system Follow
41. ateway which enhance the applicability of services Reduce the number of the inner interface Reduces the number of total interfaces from N x M interfaces to M 1 interfaces N is the number of the services M is the number of gateways Based on the above research and analysis there are several key points in the design and implement of UG UG Modular Design having characters such as unity scalability and so on UG is designed as a set of components including Gateway Configuration component Service Repository component and Socket Communication component and so on API Encapsulation According to the access requirement make corresponding adaption of this Unified Gateway interface Protocol Adaption o Socket System adapted the Client Server Socket Communication Model to pass the target command string s mapped in UG layer between MAS layer and the specific gateway s in Mote layer The Code design of Socket Port is discussed in 4 3 2 Unified Gateway Access Model Unified Gateway UG is one of the core components in H WSNMS one side it links to the service platform other side and it communicates with different real wireless sensor gateways UG adopts flexible Loosely coupled Design thinking satisfying the requirement of extension and updation The whole running environment is divided into the following two parts 33 e Gateway Configuration a series of XML files which provide the information of gateway interactivi
42. aving Mode COMS O Speed Mode COM1 COM3 COMS COM7 COM9 COM11 0 coM13 0 COM15 COM17 Power amp Speed Mode 1COM3 COMS COM7 LJCOM9 COM 1 Click Here Main Page Figure 5 6 Monitoring Ul Menu List Monitoring Platform Management 53 Sensor Network Management System Monitoring Wireless Sensor Platform Information Your Message Received client come in IP 134 68 77 90 11100 Client send is Xserve device COM5 baudrate 57600 com 0 Xserve CommandString C Crossbowycygwinibin bash login C HWUSNMS xm1 HUSNM Commands command txt 0 2010 07 15 23 38 39 xdebug could not open log file opt MoteWorks tools xserve bin logs xserve log txt No such fi 1 XSERVE 2 0 E Id xserve c v 1 8 2 3 2007 02 02 17 45 01 rkapur Exp 0 Warning Converting Windows COMS device to Cygwin device 2 Using params raw parsed converted server port 9001 3 Opening serial device dev ttyS4 57600 4 2010 07 15 23 38 42 Serial Source Msg sync 5 2010 07 15 23 38 42 7E 00 OB 7D 1B 00 00 B2 05 OO OO 33 84 81 00 00 AC 01 00 OO 71 01 82 01 9B O1 AB 01 54 01 E3 00 6 2010 07 15 23 38 42 MTS310 sensor data converted to engineering units 7 health node id 0x5b2 parent 0x00 8 battery Oxilac mv 9 temperature 0x00 degt 10 light Ox171 ADC mw 11 mic 0x182 ADC counts 12 AccelX 0x19b milliG AccelY Oxlab milliG T3 MagX 0x154 mgauss MagY 0xe3 mgauss 14 2
43. d resolving mapping issues In order to avoid those same pitfalls the Virtual Command Set Mapping Model VCSMM multi to one to multi process must include rules and guidelines addressing these issues For the solution to be flexible and scalable the implementation of a valid Virtual Command Set multi to one to multi Mapping must be included Virtual Commands For any Service Component SC containing a list of independent enumerated Virtual Commands VC1 VC2 VCn susceptible of being exchanged based on definition of VCC there must be an exhaustive set VCS of unique enumerated values in the reference function model MSA service component such that VCS VC1 VC2 VCn VC can be extended as more service components are added to the federation Properties For any Service Component containing a list of independent Virtual Command Attributes VCA referring the WSN gateway middleware information with XML file format VCA1 VCA2 VCAn susceptible of being exchanged based on the Attribute parameters there must be an exhaustive set VCAS of attributes in the reference service function model such that VCAS VCA1 VCA2 VCAn CAS can be extended based on the updation of this function component Associated Concepts For any set of Objects GWS linked through a relationship describing the Target Command concepts TC1 TC2 TCn there must be an exhaustive set TCS of concepts in the reference WSN gateway model such that TCS
44. dges whether the target command string is valid or not If not return the information about unavailable data to users if yes return the available data to users at the same time the updated related information about platform or WSN gateway status automatically is stored into the H WSNMS own database Configuration Request XML File and Mapped Result 55 56 Table 5 3 Configuration Request XML File and Mapped Command String Function Configuration Request XML File Request lt xml version 1 0 encoding UTF 8 gt Node lt Configurationreq gt XML lt gateways gt Template lt gateway gt lt gatewayname gt XServe lt gatewayname gt lt gatewayid gt 05 lt gatewayid gt lt servicelD gt 105121 lt servicelD gt lt device gt COM5 lt device gt lt interfaceboard gt MIB520 lt interfaceboard gt lt baudrate gt 57600 lt baudrate gt lt xserveterm gt xserveterm exe lt xserveterm gt lt xcommands gt lt reconfiguration gt lt xcommand gt get config lt xcommand gt lt destinationnode gt 1458 lt destinationnode gt lt update gt lt update gt lt reconfiguration gt lt powermanagement gt lt pmstatus gt lt pmstatus gt lt pmdestinationnode gt lt pmdestinationnode gt lt powermanagement gt lt xcommands gt lt gateway gt lt gateway gt lt gateway gt lt gateways gt lt Configurationreg gt Mapped e g Target Xserve S COM5 b 57600 Command Xserveterm gt get config 1458
45. e H WSNMS Platform Management Manage and Maintain Platform Information Figure 5 4 User Profile of H WSNMS 50 5 3 1 Monitoring Function and Demo Figure 5 5 shows us the Logical Flow of Monitoring function Wireless Sensor Network ued MAS UG WSN GateWay XServe 1 WSN Management Request 2 Send Monitoring Virtual Command 3 Send Target Command 4 Command valid 7 Data Unavailable 6 Data Unavailable 5 No Data Unavailable Figure 5 5 Monitoring Command Logical Flow Function User can use this function to view the real time sensor data Flow Description When Users enter WSN Management system Users send the Monitoring function request which will be wrapped to the virtual command string package then is interpreted and mapped to target command string and is sent to XServe then XServe judges whether the command string is valid If not return the 51 information about unavailable data to users if yes return the available data to users Monitoring Request XML File and Mapped Result Table 5 2 Monitoring Request XML File and Mapped Command String Monitoring Request XML File Request lt xml version 1 0 encoding UTF 8 gt Node lt Monitoingreq gt XML lt gateways gt Template lt gateway gt lt gatewayid gt 05 lt gatewayid gt lt servicelD gt 105110 lt servicelD gt lt gatewayname gt XServe lt gatewayname gt lt device gt COM5 lt device gt lt interfaceboard gt MIB52
46. e definitions referring the parameters provided by XServe in MoteWorks platform 86 Appendix D Table D 1 DataTable H WSNMS Servicinfor Vei Bal nd Value en eee ec ieee VCcode PlatformName nVarChar e gMoteWorks for Wireless Sensor Platform e g XServe gatewayName nVarChar e gXServe gatewaylD VarChar 1 OXI gt e g XServe 1 ServiceCategory nVarChar Classified into monitoring configuration reprogramming and so on e g H DataConn H Config H Repro CategoryFirstNu nVarChar 00 for H DataConn m 10 for H Monitoring 20 for H Config 60 for H Repro TT f ServicelD XMLfileName nVarChar 1 XMlfileName SocketPort nVarChar 1 Socket Port Reserved nVarChar Nu S nVarChar IN O Table D 2 Datatable H WSNMS PlatformState name Value PlatformName nVarChar ines Wireless Sensor Platform PlatformID nVarChar ae indentified number for Wireless Sensor Platform GatewayName nVarChar Gateway Name e g XServe bere EE nVarChar 0 set up 1 shut down Reserved nVarChar_ IN o 87 Table D 3 Datatable H WSNMS Socketinfor Misali BiN adi rege Value A eee code VCcode ServiceCategory nVarChar Classified into monitoring configuration reprogramming and so on e g H_DataConn H_Config H_Repro SocektIP nVarChar XXX XXX XXX SocektPort ae Socket port number Nl PG Nl G CategoryFirstNum nVarChar 00 for H DataCon
47. e design and implementation of H WSNMS involving two main technologies as follows e Mapping Model Technology e Unified Gateway Access Technology 4 2 Mapping Fame 4 2 1 Mapping Model Technology During the design the goal of Mapping Model is to map concepts command elements and relationships from the virtual commands to the target command set in order to implement a service from Client e Conceptual Mapping Conceptual mapping is the listing of all existing Virtual commands e Attribute mapping This logical step is to identify similar attributes At this level special attention has to be paid to synonyms homonyms and the inherent context of attributes Two attributes are said to be equal when they describe the same real world property e Content Mapping Most mapping efforts tend to conglomerate content mapping with attribute mapping Two values are said to be identical if they can be derived from one another At the attribute level equivalence between real world properties is established while the content level deals with how attribute values are derived from one another The complexity of any mapping effort is directly related to the complexity of these individual components 4 2 2 Virtual Command Set Mapping Model In previous traditional design Command one to one Model was adopted in the WSN management system The flexibility and reuse have been neglected 25 and more efforts have been rightly directed at identifying an
48. ening serial device dev ttyS4 57600 2010 07 15 22 44 38 Serial Source Msg sync Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel y mag_x mag_y mic values nor Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel_y mag_x mag_y mic values not Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel vY mag X mag y mic values noi Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel y mag_x mag_y mic values nor Query INSERT into mts310 results result time nodeid parent voltage temp light accel x accel y mag_x mag_y mic values nor Receive my Message 2010 07 15 22 44 37 xdebug could not open log file opt Motellorks tools xserve bin logs xserve log Figure 5 17 Demo of New Data Collection 5 4 XServe s Extension This section is not the very important part in the design and implement of H WSNMS Architecture but worth mentioning mainly considering the extension on some specific WSN gateway middlewares such as XServe for the future system developers thus H WSNMS also can extend some new Virtual Command Sets it needs The following is our extension based on XServe which displays the flexibility and scalability of H WSNMS In Figure 5 2 Three tier architecture instantiation based on XServe in which we put forward to an idea of extending the c
49. erlying idea of H WSNMS is to decouple the development of application specific management functions from deployed heterogeneous WSN platforms and gateway technologies including their associated preliminary management command services H WSNMS architecture not only directly supports network management for heterogeneous WSNs but also facilitates the reuse of each individual WSN s preliminary management tool as much as possible and at the same time presents to users a unified interface UG across multiple WSNs We illustrated the H WSNMS using XServe mote network through mapping H WSNMS Virtual Commands to both the existing XServe Command Service and the newly extended XServe Command Service to realize the flexibility and scalability of H WSNMS Our current H WSNMS prototype is 73 developed in Java We plan to extend our prototype system to include two and more different WSN platforms and gateway technologies at the Mote layer to further study and verify our proposed new H WSNMS architecture We also plan to create more sophisticated management functionality at the MSA layer by the composition of a sequence of Virtual Commands LIST OF REFERENCES 1 2 3 4 9 6 7 8 9 10 11 12 13 74 LIST OF REFERENCES Chee Yee Chong SP Kumar Sensor Networks Evolution Opportunities and Challenges Proc IEEE vol 91 no 8 2003 pp 1247 56 Wei Zhao Yao Liang Qun Yu Yan Sui H W
50. erver dbport dbname dbuser l xmlfile xmlp xmlport After completing the mapping procedure Socket in UG Layer has been applied as the communication method between the MAS layer and Mote Layer A different type function has a different communication port for it We design a 3 socket port management mechanism to achieve this aim The method is described as following As mentioned in section 3 3 1 in which the Table 3 1 shows us the main Command Category and Specification of VCS The Table A 1 in Appendix A gives us the detail definition of various parameters involved in the whole design of H WSNMS including a series of code rules such as the code definition of WSN platform the code definition of WSN gateway and so on The Based on the Table A 1 or the following Table 4 2 we design the Definition of ServicelD or called as VCID and Socket Port Table 4 3 Specification of Code Y 1 9 Re o VCS Code extendable 70 H_others ServicelD code is composed of 6 digital numbers which is used to tag each VC PlatfformID GatewaylD GatewayCode VCC No Socket Port Code is made up of 4 digital numbers which is used to tag Socket Port and the XML file name PlatformID GatewayCode VCC No Following the code rule in Table A 1 or Table 4 2 take Data Collection Function based on XServe provided by MoteWorks platform with specific communication port COM5 as an example ServicelD Code 1 05 1 00 1 PlatformID MoteW
51. ervice Proxy A series of XML files in Service Wrapper are sent to Service Proxy in UG layer to be mapped and interpreted into a target command string authorized by specific WSN gateways in the Mote layer 18 e Gateway Access It builds up the gateway middleware connection mechanism between UG layer and Mote layer e Communication Mechanism Socket Client Server model is adapted in this system which becomes the communication channel between MSA layer and Mote layer 3 3 1 UG Metadata Repository UG Metadata Repository UG MR is a series of available files to describe the information about WSN platforms and their gateways It has two functions one is to complete the respective configuration of WSN platforms the corresponding specific gateways and gateway middleware application interface and the other is to help to connect with mote layers through Gateway Access component and Communication Mechanism component As mentioned in section 3 2 1 automatically created socket communication port for management services with same type needs the information about the code of VCC the code of WSN platform and the code of WSN gateway The latter two codes are described and defined in the Metadata Repository in UG layer The detail code rules refer the Appendix A which includes more details e Platform Configuration The target platform information is defined such as Platform Name and Platform ID and the corresponding Gateway Code in these metadata fil
52. es e Gateway Configuration The corresponding Gateway Name Gateway ID and Gateway middleware application interface will be described in these metadata files 19 3 3 2 Service Proxy It is a XML Parser responsible for systematic parsing and interpreting of the Virtual Command s with XML format wrapped by Service Wrapper to the target command strings indentified by the specific WSN gateways in Mote layer This Mapping processing is completed by Service Wrapper presenting VCS with XML format and Service Proxy containing a group of Service Proxies which is command interpreter for a subset of VCS That is to say in H WSNMS system the combination of Service Wrapper and Service Proxy is a key Mapping Technology of H WSNMS system implementation Mapping Technology which will be discussed in section 4 2 3 3 3 Gateway Access Through a series of available files configuring various WSN platforms their different gateways information and relative gateway middleware information and so on Gateway Access component builds up a connection mechanism with the specific gateway middlewares The combination of MR component and Gate Access component is another key technology of H WSNMS system implementation Unified Gateway Access Technology which will be discussed in section 4 3 It is responsible for connecting the available application interfaces from the various different WSN gateway middlewares take an instance of specific gateway middleware XSe
53. et_groupid lt destination address gt lt new group id gt set_rfchannel lt destination address gt lt new rf channel gt set_rfpower lt destination address gt lt new rfpower gt sleep lt destination address gt wake lt destination address gt reset lt destination address gt xserve shutdown actuate lt destination address gt lt device gt lt state gt device ids states green led 0 off 0 yellow led 1 on 1 red led 2 toggle 2 all leds 3 sounder 4 relay1 5 relay2 6 relay3 Categor Power Management Basic Update Rate Mote Configuration Parameter Settings Actuation 82 Table B 5 XCommand Categories and Description RESET SLEEP WAKEUP SET RATE e GET CONFIG e SET NODEID e SET GROUP e SET RF POWER e SET RF CHANNEL ACTUATE e SET LED e SET SOUND e SET RELAY Description To reset the sleep and wakeup time To get or set the update rate The set rate command changes the data acquisition duty cycle of the mote The first argument is the new timer interval in milliseconds This set of commands allows you to get and set radio frequency and power including channel This set of commands actuates each individual LED with the option to operate on all three LEDS This command turns the sounder off or on This command turns the relays on Table B 6 XServe Reprogram Line Parameters Usage xserve lt rla p c xrlxp xc dbxmir xmlp xmiec v alert m gt displa
54. eters c cccccccceeeceeeseeeeeeeeeeeeeeeeees 81 Table B 5 XCommand Categories and Description ccceceeecseeeeeeeeeeeeteeens 82 Table B 6 XServe Reprogram Line Parameters cccccceccceeeseeeeeeeeeeeeeeeeeees 82 Table B 7 XOtap Command Arguments rarrrannnarnnnrnanernnnvannnannnannneennnennnnnnenneen 83 Table C 1 Monitoring ServicelD Definition rrarrrrrrarrnrrrarvnrrrervannnernarnnneneennnnn 84 Table C 2 Configuration ServicelD Definition rrrrrarrnrrrarnnrenrrannnrrrarnnnenernnnnn 84 VI Appendix Table Page Table C 3 Reprogram ServicelD Definition rrrrrrrarnnrrnarvarenerrarnnernarnnneneennnnn 85 Table C 4 Data Collection ServicelD Definition rrarrrarnnarnnarnnrrnnrevaneranenannnnnn 85 Table D 1 DataTable H WSNMS Servicinfor rrrrarrnrrrarnnrrnnrnnnnnernarnnneneennnnn 86 Table D 2 Datatable H WSNMS PlatformState rrarrnnrrarnanennrnannnnrnnnnnnenernnnnn 86 Table D 3 Datatable H WSNMS Socketlnfor rrrrrrurrnrrnrnnnnnnnurvnnnnnvnennneneenenn 87 Table D 4 Datatable H WSNMS GatewayConfig rrarrrarnrannnernnnrnarevannnnnnnnnn 87 Vil LIST OF FIGURES Figure Page Figure 2 1 Sensor Platform MICAZ rrrnnnrnnnenannnannnannnnnnnnrnanenannnannnnnnnnnnnnnnnnennne 3 Figure 2 2 Sensor Platform Particl sirenes E EE Ea 4 Figure 2 3 Sensor Platform Node rronnnannranerannnannnarnnnrnnnerannrannnannnennnnenanennsnnnen 5 Figure
55. ev Raje for their wonderful courses learned a lot from these inspiring classes and have applied what gained in these classes to my research work am also thankful to many department staff including but not limited to Joshua Nicole DeeDee and Scott and all people and students especially Rui Liu Wei Zhao from my department for their patience and help as they came along with me during this process Finally would like to thank my parents for their love and support TABLE OF CONTENTS Page STORT PE ge me eg eet eee er ee a enn ee V OS OF VG IRE Hav4r4rv4r4rr RR vil ABBREVIATIONS 4 IX PS TRAN XI CHAPTER T INTRODUCTION suser 1 LL RESEA ON BACK OQMOUNO ve 1 TREE 2 CHAPTER 2 RELATED WORK cenicdn cuntvenesnsesnseenincesapainsacosaioomenntuoamsnieonmumlesmeets 3 2 1 Current Sensor Network Platforms rrarrranrnanrnnrnnnrvnnenannvannnnnnnnrnnnenannnnne 3 21 1 MoteWorks PROM uvaner Tab a 3 212 FATTE PETE 4 2 13 PINOGC PAMIR E 4 2 2 Sensor Network Middleware Architectures rrrarrrarrrarrrarrrnrnnernnrrnnnennne 5 2 2 1 MoteView Framework rrarrarnannnnnnnnnnnnnrnnrnnrnnnnnnnnnnnnnannannnnnnnnnnnnnnnnnnee 6 2 2 2 Atlantis FFAMEWOMK ccccc ccc ecc eee eceeeeeeeeeseeseeseeeecseeeeeseeseeseeseeeeeeeesaes 6 2 2 3 Decentralized Enterprise Systems Framewokk ccccseceeeeeeeeeeeees 6 CHAPTER 3 r VWSNMS AROMTEGTURE sass aie tos aidan seeded suilealnanodeateieeoiadats 8 3 1 H WSNMS Sys
56. get commands accessing heterogeneous WSNs then the specific gateways sends the request to the WSN motes through this way building a real time interoperation e Reduce the implication on platform services from changes of GW From the services in platform what they face is not complex multiple gateway interfaces any longer but a standard interface provided by a Unified Gateway UG Thus when a gateway with updated version or a new gateway accesses only revise and increase the corresponding configuration component Gateway Configuration in UG based on the updated or new gateway protocol the platform services will not be impacted e Improve the reliability of platform accessing After applying the Unified Access Technology to the service platform UG becomes a unique channel between the Comprehensive Application Platform and Wireless sensor Networks which can better manage and monitor the relatively messy interfaces in Traditional Access Mode and more effectively improve the reliability of platform accessing e Promote the quick development and deployment of services When exploring new services need not consider the compatibility of multi protocol based on a completed function Unified Gateway thus the period 32 of development and deployment of new applications is shortened along with Enhance the general applicability of developed services The development of new services does not involve the adaptable problem of the specific g
57. he commands they will response the corresponding information back to the WSN Base Station and then the Base station transfers this information to WSN gateways to translate and send the data and WSN information back to Users through Unified Interface During the Response processing as the dash line shown the retrieved data from WSNs motes and the updated information about platform status are stored into H WSNMS DB We will overview several functions in detail such as Monitoring Reconfiguration and Reprogram one by one in the later Chapter 5 to show the different logic flows of various management functions Request Display MSA VCS Commands Components Acknowledge or LP Figure 3 5 General control and status information flow for Generic Functions 22 23 CHAPTER 4 H WSNMS KEY TECHNOLOGIES AND IMPLEMENTATION 4 1 System Logical Architecture and Key Technologies Overview This Chapter will focus on discussion of the key technologies and system implementation Figure 4 1 shows us the Logic Architecture of H WSNMS which involves two key parts during the design and implement of H WSNMS Mapping Fame and Access Adaption Application Content Application Management Platform GWs GWI En GWn WSNs Platforms Network Ev lt lt See Figure 4 1 H WSNMS System Logic Architecture 24 Mapping Fame and Access Adaption are key parts in th
58. hitecture working as an extensible and scalable interface between management components and concrete WSN gateway s provides an Access Adaption to specific WSN gateways which also is discussed as another key technology in Chapter 4 Besides to illustrate implementation of the H WSNMS architecture more detail in the Chapter 5 we will present an instantiation based on specific WSN platform Crossbow s MoteWorks 6 In the following sections the three Layer structure is analyzed layer by layer 3 2 Management Service and Application Layer Management Service and Application MSA layer not only is able to provide management functionality but also benefit from the uniform interfaces offered by the UG layer In the Figure 3 3 gives us the detail about the MSA layer 13 Service Components Monitoring Reprogram Data Collection Configuration MSA Layer Gateway VCS Config Service Config gt T a XML XML Service Wrapper UG Layer H WSNMS DB Figure 3 3 Management Service and Application Layer There are two main parts in this layer e Service Components e MSA Metadata Repository It contains a series of metadata documents in following components o VCS Configuration o Gateway Service Configuration o Service Wrapper 3 2 1 Service Components The MSA layer presents lots of various WSN
59. hod with format IHEX e Query users can optionally query a node when it is running the OTAP Image to get information about different slots e Boot reboot all chosen nodes to OTAP specified Image 60 e Download specify the nodes we want to program and specify the slot Select the binary image of the app main ihex which is implemented and compiled by NesC language As the OTAP progresses you will see the report in terms of number of pages downloaded into the flash Flow Description When Users enter WSN Management system Users send the Reprogram function request which will be wrapped to the virtual command string XML package which is interpreted and mapped to the target command string after XOTAP receives the target command string and judges whether this mapped command string is valid or not If not return the unsuccessful information to users if yes return successful information thus users can use reprogram function successfully to upload the programming into motes in WSNs Reprogram Request XML File and Mapped Result 61 Table 5 4 Reprogram Request XML File and Mapped Command String Function Reprogram Request XML File Request lt xml version 1 0 encoding UTF 8 gt Node lt Reprogramreq gt XML lt gateways gt Format lt gateway gt lt gatewayid gt 05 lt gatewayid gt lt vcid gt 110161 lt vcid gt lt COMport gt COM5 lt COMport gt lt baudrate gt 5 600 lt baudrate gt lt interfaceboard
60. initions refer to the Appendix A C 58 Demo Sensor Network Management System Configuration Mote Configuration Menu List p nn Group ID Submit Get Config Note ID 11458 Set NoteID Old Node ID New Node ID Set Collection Rate Node ID Buffer Size Set Sampling Rate mm Node ID Collection Rate Network Power Management Set Wake Node ID WAKE Set Sleep Node ID Set Reset Node ID RESET Gateway ShutDown Figure 5 9 Configuration Ul ommand is get config 1458 SUCCESS Command executed successfully SUCCESS Success NODE ID 1458 UID OLE9DAD70E000012 GROUP ID 125 RADIO CHANNEL 11 RADIO POWER 31 Figure 5 10 Demo of Get Config 59 5 3 3 Reprogram Function and Demo Figure 5 11 shows us the Logical Flow of the Reprogram Function Wireless Sensor Network Base Station WSN Gate Way XServe XOTAP 1 WSN Management Request 2 Send Reprogram Virtual Command 3 Target Command 4 Command valid 7 Return unsuccessfully information 7 Return successfully a 6 Return Response Yes Query Boot and Download executed successfully 6 Return Response 5 No Request unsuccessfully Figure 5 11 Reprogram Command Logical Flow Function Query Boot and Download program to the motes through OTAP met
61. ion which is responsible for storing the responded data from motes in WSNs 36 Table 4 2 Wrapped XML Template File and Mapped Command String Function Data Collection Request XML File Request lt xml version 1 0 encoding UTF 8 gt Node lt Datacollreq gt XML lt gateways gt Format lt gateway gt lt gatewayname gt XServe lt gatewayname gt lt gatewayid gt 05 lt gatewayid gt lt servicelD gt 105100 lt servicelD gt lt device gt COM5 lt device gt lt interfaceboard gt MIB520 lt interfaceboard gt lt baudrate gt 57600 lt baudrate gt lt dbinfor gt lt dbserver gt 149 166 32 252 lt dbserver gt lt dbport gt 5432 lt dbport gt lt dbname gt IDAM lt dbname gt lt dbuser gt tele lt dbuser gt lt dbpasswd gt 12345678 lt dbpasswd gt lt databaseparsed gt lt databaseparsed gt lt xmlfile gt XmlStream xml lt xmifile gt lt xmlp gt lt xmlp gt lt xmlport gt 9005 lt xmlport gt lt dbinfor gt lt gateway gt lt gateway gt lt gateway gt lt gateways gt lt Dataconnreq gt Mapped xserve S COM5 b 57600 dbserver 149 166 32 252 Target dbport 5432 dbname IDAM dbuser tele Command xmlfile XmlStream xml xmlp xmlport 9005 String This is a General and Extendable file Example Available Command parameters for XServer Refer XServe Users Manual in which there is the detail introduction about various XCommand Arguments main parameters xserve s b dbs
62. n 10 for H Monitoring 20 for H Config 60 for H Repro re Hm Table D 4 Datatable H WSNMS GatewayConfig ee ai bd gt Os name Value Li iad Nia al e VCcode PlatformName Pf Wireless Sensor Platform PlatformID nVarChar Unique indentified number for a Sensor Platform EfilePath ete Executable file Path ed EE Executable file e g XServe exe XServeterm exe XToap exe Reservedt nVarChar IN S Reserved2 nVarChar INN S MSA Layer UG Layer Mote Layer Appendix E i WSNs Service and Application Users q Service Components Configuration Reprogram Data Collection Platform EN Gateway U Gateway Access i e __ Communication Mechanism Gateway1 z Sensor Networks H WSNMS DB Figure E 1 the Whole Design of H WSNMS 88
63. name dbuser l xmlfile xmlp xmlport 67 Function Information Description Data Collection Service based on XServe provided by Mote Works platform with communication port COM5 Service Code 1 05 1 00 1 MoteWorks PlatformID 05 Device GatwaylD COM port COM5 1 Gateway Code of XServe 00 H DataColl Data Collection VC Code Socket Port Code 1 1 00 1 Platform Code or PlatformID MoteWorks produced by Crossbow 1 Gateway Code of XServe 00 Data Collection VCS Code 1100 Socket Port 1100Req xml Data Collection Function XML file name Note the code rules and definitions refer to the Appendix A C 68 Demo Welcome to HWSNMS Management Platform Data Collection Wireless Sensor Platform Information Menu List Please Select Wireless Sensor Platform Monitering Woo J Please Select Interface Board mesio Hep sd Please Select Baud Rate Platform Management 57600 v Please Select Serial Port COMS v Please Select Wireless Sensor Platform XMTS310 v Note Data Collection Click Here New Note Data CollectionClick Here Main Page Figure 5 15 Data Collection Ul Sensor Network Management System Data Collection Wireless Sensor Platform Data Collection mts310_results result_time nodeid parent voltage l temp light accel x laccel y mag x mag y Menu List 2010 07 08 23 06
64. nd After deployment the uNodes self organize into a multi hop network through which data can be routed back and forth to a designated sink node This platform is ideal for building large scale sensing infrastructures that can function unattended for long periods of time Since many chemicals must be stored under specific ambient conditions we use the uNode sensors for continuously monitoring environmental conditions Figure 2 3 Sensor Platform uNode 2 2 Sensor Network Middleware Architectures Some of the hot topics in WSN software research include such as Security Mobility when sensor nodes or base stations are moving and Middleware the design of middle level primitives between the software and the hardware This thesis focuses on the research on sensor network middleware architectures Today due to the unique challenge of WSN 2 typically the platforms are specialized for specific purposes e g data collection target tracking it is often the case that complex applications require the combination of multiple proprietary technologies and heterogeneous wireless sensor platforms As a result the management monitoring and administration of a system with highly distributed logic are a very complex task Without the right tools and architecture it can increase the total cost of ownership to a point where the deployment of this technology becomes commercially uninteresting 2 2 1 MoteView Framework Mote View 5 9 pre
65. nnen 33 4 4 1 H WSNMS Software Architecture Overview rrarraranrrnarnnrrnnrnannnernnn 33 4 4 2 System User Interface Design rarrranrnnnnnnrnnnrnanrnannnannnnnnnnrnnnennnnnnne 35 4 4 3 XML Template and Definition rrrrrarnnrrnnrnnnrrnrrannnerrarnnnennrnnnnneennnnnn 35 4 4 4 Data Structure and Definition rrrrarnnnrnarnnnrrnrrannnnrnnnnnnnnnrnnnnnernnnnnn 40 CHAPTER 5 H WSNMS CASE STUDY i ervarvanvvnrrnrennrrnnrssevsnrnvenevrnnnnsennnnnsennennne 42 5 1 Experiment Hardware rrannannnnnnnnnnnnnnnnnnernnnnnnnannunnannannannannnnnnnnnnnnnnnnnnee 42 D2 STATE PE O MM siniensincoiovaieiacoraiciques alcsanensicianazniaiaceaioimenaieinimaaioumummnieion 45 Sa Cent NER pr 45 5 2 2 Specific Gateway Middleware rrrnnrnnnenannnannnnnnnnrnnnrnnnnnannnnnnnnrnnnennn 46 5 Maln FUNCIONS OVERV GW sne 48 9 3 1 Monitoring Function and Demo rrarnannnnrnannnnrnnnnnnrnarnnnnnernnnnnnnnennnnne 50 5 3 2 Configuration Function and DEMO esrara aanraai 54 5 3 3 Reprogram Function and Demo arrnnnnnrnnnnnnnnanvnnnnnrnnnnnnnnnnnnnnnnnnnnre 59 5 3 4 Data Collection Function and Demo rrrarnnrrnnrnnnenernannnernnannneneennnnn 64 S XSENES EXIENSION onarri oa e E TAEAO 69 CRAP TER 96 FUTURE WORK ceraristiriin iinan a a SA 12 STOR REFEREN ESN 74 APPENDICES FEN 0121 10 Gi ae ee eee ee eee NE mn tert Tf PAPPENIK B roari aE E 19 APPENAKE venne 84 PAD DCW OI De 86 APPENIK E vaska nda 88 LIST
66. o which H WSNMS maps some Virtual Commands To realize the mapping from a subset of Virtual Command Set to a concrete WSN gateway Command Service H WSNMS adopts three layer architecture The top layer is the composition of different WSN management components The bottom layer consists of multiple heterogeneous WSN gateways associated with their preliminary management Command Services The middle layer is the core of our proposed H WSNMS architecture that is responsible for interpreting and mapping each Virtual Command from VCS into a concrete WSN gateway Command Service s through this layer and the VCS H WSNMS can make management components more reusable across heterogeneous WSN platforms and also easier to develop because developers can create management components based on predefined VCS and be freed from handling the details early on with the variety of WSN platforms in the section 5 4 of Chapter 5 VCS reuse and extension are studied and implemented 12 The advantage of VCS is that when a minor change on the commands service happens just update some parameters configuration or add new parameters to complete new configuration in the interpreter For understand this better the content and format of VCS is defined in the Table 3 1 For this Wrapping and Interpreting procedure of VCS we call it Virtual Command Set Mapping Model VCSMM which is discussed as one of key technologies in Chapter 4 The core UG layer in our proposed H WSNMS arc
67. ol machine health monitoring environment and habitat monitoring healthcare applications home automation and traffic control and so on Wireless Sensor Networks have become an emerging new research area in the distributed computing environment It plays an important role in the pervasive computing to support a wide range of applications of the daily life in future So far as heterogeneous WSNs are being widely deployed for various applications we are faced with a new challenge of network management for heterogeneous WSNs On one hand current available WSN management tools are either application specific or platform specific thus suffering from the lack of reusability in heterogeneous WSNs management environment On the other hand to develop a new WSN management system for heterogeneous WSNs from scratch is time consuming and may not be feasible Motivated by such a challenge a major impediment in the integration process is represented by the variety of customized platforms and proprietary technologies In this thesis we propose a unique open scalable and flexible WSN Management Comprehensive Application Platform targeted for Heterogeneous WSNs Management System Our prototype system H WSNMS provides a Web based Data and Network Management Environment for Heterogeneous Wireless Sensor Networks This research topic is very important to allow large scale heterogeneous WSNs to be effectively and easily managed and operated in the real world t
68. ommand library in XServe to improve the Configuration function Considering no any source code we would not extend the dll file about XServe parameter command set 2 proposes an extension method based on the XServe configuration existing available XCommand Set XServe provides the only entry i e port 9003 7 for XCommand inputs After a mapped target command is wrapped in a packet and injected to wireless mesh network XMesh it will follow the flow shown in Figure 5 18 the command for configuring sampling rate will be finally executed and the 70 acknowledge packet will be sent back to base station In our application except for periodic data collection on each mote the following functions are needed from the client side with XCommand e Set Collection Rate push sampled data to a queue structure and collect all sampled data at the end of each automatic collection period e Enforced Collection send back all existing data samples in the queue These two configuration functions have been implemented through relocating the XCommand SET RATE value field In Figure 5 19 the highlight with red line shows us the demo of above extended configuration functions Sensor Node Location Local Application Group ID Node ID J Unpack Check on Command Parameter Group 124 0X20 RESET SLEEP Set Sampling Rate WAKEUP Set Collection Rate SET RATE Agent x ASETYVE Tier VCS Mapping Enforced
69. on products include the MICA2 4 868 916 MHz and MICAz 2 4 GHz motes as shown in Figure 2 1 and the Intel designed IMOTE2 Crossbow also makes a software design platform for its hardware called Mote Works The MICA2 Mote is a third generation mote module used for enabling low power wireless sensor networks The MICA2 processor radio is fully supported by the MoteWorks Software Platform MICAz is a wireless sensor network mote developed by Crossbow Technology The device is built upon the IEEE 802 15 4 standard It is one of the most commonly used mote system in the world Figure 2 1 Sensor Platform MICAz 2 1 2 Particle Platform The Particle node 13 produced by Particle Computer comprises a communication board with the PIC18f6720 microcontroller and TR1001 transceiver Various types of sensors can be attached to the communication board The wireless communication uses the AwareCon protocol 20 which is designed to handle high mobility and density of nodes This makes the Particle platform as shown in Figure 2 2 well suited for equipping chemical containers handled by human operators and checking potential dangerous situations Figure 2 2 Sensor Platform Particle 2 1 3 uNode Platform The uNode platform 14 as shown in Figure 2 3 produced by Ambient Systems represents a low power general purpose sensor node built around the MSP430 microcontroller and a single chip radio transceiver for the 433 868 915 MHz ISM ba
70. orks produced by Crossbow 05 GatwaylD XServe COM Port COM5 1 Gateway Code of XServe 38 00 Data Collection Service VC code 105100 DataCollection Function based on XServe provided by MoteWorks platform with communication port COM5 Socket Port Code 1 1 00 1 Platform Code or PlatformID MoteWorks produced by Crossbow 1 Gateway Code of XServe 00 H DataColl Data Collection Service VCS code 1100 Socket Port 1100Req xml Data Collection Function XML file name Each application function for the same WSN platform has unique Socket Port so we name the wrapped XML file name of this function as Socket Port Req xml and store this XML file into the corresponding folder with same name as the name of WSN platform under the given path The Service Proxy will automatically find this XML file with name Socket Port Req xml to interpret and map it to the Target Command string The code of ServicelD and the code of Socket Port are not limited the 6 digital numbers or 4 digital numbers they can be extended according to design requirement From Table A 1 or Table 4 2 the PlatformID GatewaylD GatewayCode are extendable and the extension of them can be completed in the corresponding configuration files which displays the scalability and flexibility of system design In MSA layer another component Gateway Service Configuration component provides a series of XML files as shown in Table 4 3 Table 4 4 and so on The Table 4
71. pplication via wireless communication The XOtap 8 application is a server side tool that works either with XServe or directly connected to the serial port of the XMesh Gateway to communicate with the XMesh network It resides in the XServe Layer in a remote or local server or Stargate of the XMesh Network landscape Users use XOtap to download program images to the Motes by having the application first read an IHEX image file name and a list of Motes to download Then the image is downloaded to each Mote Appendix B represents a series of various available command parameters referring the XServe Manual 7 and Mesh Manual 8 provided by CrossBow MoteWorks Appendix C makes some definitions for different functions based on the Code Rule in Appendix A and available command parameters statement in Appendix B Based on these XServe features several web based WSNs management functions have been designed and developed which will be introduced in the following section 48 Crossbow s XServe is used as one instance of specific WSN platform s gateway technology to be handled by the Unified Gateway in the H WSNMS architecture as shown in Figure 5 2 We demonstrate the design idea through developing several management components Monitoring Reconfiguration Reprogram and so on From the client tier point of view these management components execution details are hidden from users In general partial functionality of commands required by management
72. rve in Crossbow WSN platform MoteWorks which provides several different application interfaces such as XServe XServterm and XOtap and so on Through these application interfaces the mapped target command s from Service Proxy is are sent to the specific WSN gateway s to complete various WSN management or data collection functions About Gateway Middleware XServe will be introduced as an instantiation of system implementation in Chapter 5 20 3 3 4 Communication Mechanism Communication Mechanism component adopts Socket Client Server Model to realize the communication between MSA layer and Mote layer After Service proxy interprets and parses Virtual Command s described by XML file the output mapped target command string s will be sent to the WSN gateway through this Communication Mechanism component The socket port is automatically created based on the code of VCG the code of platform and the code of WSN gateway in another words these code information should be defined at the beginning by system developers as illuminated in the Table 3 1 Appendix A and Appendix B the detail definition of Port No i e Socket Port will be introduced in section 4 4 3 3 4 Mote Layer The Mote Layer the system hardware layer building the real word wireless sensor network or wireless sensor networks Each wireless sensor network has its own base gateway communicating with its specific base station The UG Layer provides a Unified Interface
73. s Sensor Networks 2005 pp 278 289 W S Jang W M Healy M J Skibniewski Wireless Sensor Networks as Part of a Web Based Building Environmental Monitoring System Automation in Construction 17 2008 pp 729 736 F Yang Enterprise Mashup Composite Service in SOA User Profile Use Case in 2008 IEEE Congress on Services Part I 2008 pp 97 98 29 30 31 32 33 34 39 36 37 38 39 40 76 J C Yelmo J M del Alamo R Trapero P Falcarin J Yu B Carro and C Baladron A user centric service creation approach for Next Generation Networks in Innovations in NGN Future Network and Services 2008 K INGN 2008 First ITU T Kaleidoscope Academic Conference Geneva Switzerland IEEE 2008 pp 211 218 D Woods and T Mattern Enterprise SOA Designing IT for Business Innovation O Reilly 2006 C Bornhovd et al Integrating Smart Items with Business Processes An Experience Report Intl Conf Sys Sci 2005 M Beigl et al Awarecon Situation Aware Context Communication UbiComp 2003 pp 132 39 M Marin Perianu T J Hofmeijer and P J M Havinga Implementing Business Rules on Sensor Nodes 17th IEEE Int l Conf Emerging Technologies and Factory Automation 2006 pp 292 99 M Marin Perianu and P J M Havinga RMD Reliable Multicast Data Dissemination within Groups of Collaborating Objects Local Comp Networks 2006 pp 656 63
74. sents a scalable software framework for managing monitoring and visualizing sensor network deployments developed by Crossbow It provides tools to the users to visualize results from a sensor network Readings arriving from the network are stored in a relational database The sophisticated interface is used to check the motes readings on the fly visualize the topology produce graphs from selected motes check their status and export the readings to a spreadsheet 2 2 2 Atlantis Framework The Atlantis Framework 15 is based on TinyML but addresses several of its shortcomings The basic elements are the same i e it can describe fields platforms and sensors Additionally the Atlantis Framework adds data handling abstractions and a query field for more detailed queries It makes further improvements by defining a field task object which can handle asynchronous data retrieval For this purpose it adds an additional data broker which handles the tasks and specific broker behaviors to describe how to handle the task itself As a nice roundup the Atlantis Framework adds data filters and event subscription possibilities On the downside there is not a standard way to manage the sensor systems since a registry does not exist 2 2 3 Decentralized Enterprise Systems Framework The overall architecture of the Decentralized Enterprise Systems framework 11 12 used a service oriented architecture SOA as a platform construct SOA architect
75. tNID set nodeid lt destination address gt lt new node id gt 105124 H Config Reconfig SpRate set rate lt destination address gt lt new rate gt 105125 H Config Reconfig CRate set collection rate lt destination address gt lt new size gt 105126 H Config Reconfig ECollect set manual collection lt destination address gt lt Flag gt H Config PM VCS NXXY40 NXXY59 extendable ServicelD Description 105140 H Config PM WAKEUP wake lt destination address gt 105141 H Config PM SLEEP sleep lt destination address gt 105142 H Config PM RESET reset lt destination address gt 105143 H Config PM SHUTDOWN xserve shutdown 85 Table C 3 Reprogram ServicelD Definition H Repro VCS NXXY60 69 extendable ServicelD Description 4 105161 H Repro BOOT C Crossbow cygwin opt MoteWorks tools xotap bin cygwin x86 xotap exe 2 p v 2 7 sf localhost 9001 1458 105162 H Repro QUERY C Crossbow cygwin opt MoteWorks tools xotap bin cygwin x86 xotap exe 2 q v 2 7 sf localhost 9001 1458 105163 H Repro LOAD C Crossbow cygwin opt MoteWorks tools xotap bin cygwin x86 xotap exe 2 f C main exe ihex v 2 7 sf localhost 9001 1458 Table C 4 Data Collection ServicelD Definition H DataColl VCS NXXY00 extendable 105100 H DataColl xserve S COM5 b 57600 dbserver 149 166 32 252 dbport 5432 dbname HWSNMS dbuser tele xmlfile XmIStream xml xmlp xmlport 9005 Note The abov
76. tation have been properly quoted and attributed I certify that all copyrighted material incorporated into this thesis dissertation is in compliance with the United States copyright law and that I have received written permission from the copyright owners for my use of their work which is beyond the scope of the law I agree to indemnify and save harmless Purdue University from any and all claims that may be asserted or that may arise from any copyright violation QUN YU Printed Name and Signature of Candidate 07 23 2010 Date month day year Located at http www purdue edu policies pages teach res outreach viii 3 1 html DESIGN AND IMPLEMENTATION OF WEB BASED DATA AND NETWORK MANAGEMENT SYSTEM FOR HETEROGENEOUS WIRELESS SENSOR NETWORKS A Thesis Submitted to the Faculty of Purdue University by Qun Yu In Partial Fulfillment of the Requirements for the Degree of Master of Science August 2010 Purdue University Indianapolis Indiana ACKNOWLEDGMENTS This thesis would not have been possible without the help and support of many people I would like to express my deepest gratitude to my adviser Prof Yao Liang His supervision helped expedite my research progresses and open the door to new discoveries also would like to thank my committee members Prof Yuni Xia and Prof Xukai Zou for their time and guidance In addition would like to thank Prof Arjan Durresi Prof Yuni Xia Prof Xukai Zou and Prof Raje
77. tem Framework OVErview ccccccceecceceeeeeseeeeeeeeeeeeeeees 8 3 2 Management Service and Application Layer rrarrrarnnnnnnnrvanevanennnnnnnn 12 2 SEE COMPONEN S arve 13 3 2 2 MSA Metadata Repository arrrnrrnnrvnnenanrvanrnannnnrnnnennnnnannnnnnnnrnnnennn 14 JE Gateway LAS 16 3 3 1 UG Metadata Repository arrrarrrnrnnnrrareranevanrrannnernnrennnrrannnnnnnannnsennn 18 332 SEMES PIONER 19 9 33 GaleWdy ACCESS eee NER 19 3 3 4 Communication Mechanism rarnnnrnnnenanerarrrannnernnnrnnnenannnnnnnannnnennn 20 SJ 0 WAY EE e 20 JSENSNUS DB uvaner 20 3 6 System General Function Logical Flow rrranrrnanenannnannnannnnrnnnenanennnnnnnn 21 CHAPTER 4 H WSNMS KEY TECHNOLOGIES AND IMPLEMENTATION 23 4 1 System Logical Architecture and Key Technologies Overview 23 22 WIAD DINIGI FANE ee AANGEN 24 4 2 1 Mapping Model Technology ccccccceecsecceeeseeceeeeeeseeeeeeseeseeeeeeees 24 4 2 2 Virtual Command Set Mapping Model rrarrrnrnannnrnnrnnnrnnrnannnernnnnnn 24 4 2 3 VCSMM Application Case DISCUSSION cccecceceseeeeeteeeneeeeeeeeeees 2 Page 4 ACCESS AAN Le 30 4 3 1 Unified Gateway Access Technology cccccceecceeeceeeceeeaeeeeeeeeees 30 4 3 2 Unified Gateway Access Model rrrnrnarrnanrnannnanenannnannnnnnnnrnnnennnnnnne 32 4 4 H WSNMS Implementation rrrrarrarrnnrranrnerrannnnrnnrnnnrnernannnernnsnnenneen
78. to a target command string authorized by specific WSN gateways in the Mote layer 3 3 Unified Gateway Layer Owing to the difference of WSN gateways and diversity of command parameters indentified by motes in different WSNs during the design of Unified Gateway UG layer the system developers should statistics enough integrated information from Mote Layer the purpose of which are to transfer various valid command strings to motes smoothly to achieve gateways configuration correctly and to guarantee gateway communication mechanism work successfully and so on The design and implement of UG layer is not only a challenge but also an opportunity The Figure 3 4 shows us the detail about the UG Layer 17 MSA Layer UG Metadata Repository Platform Gateway Gateway Song omg Access UG Layer Communication Mechanism Mote Layer Figure 3 4 Unified Gateway Layer UG layer is designed to harmonize different sensor platforms i e heterogeneous sensor platforms e Responsibilities o Handle the proprietary WSN mechanisms o Expose the service oriented functionality through a standard interface e Uniform Interface o Facilitates the integration of the new platforms via a simple standardized mechanism There are three main components in this layer e UG Metadata Repository It contains two type metadata documents as following o Platform Configuration o Gateway Configuration e S
79. ty and real time monitoring and control in the future the system developer can design a Web based or MS Window based Virtualization Tool to complete gateway configuration e Gateway Access Loader Through this Loader some certain gateway can be start up shut down and configuration When a gateway starts up through gateway configuration component the configuration information or the prescribed configuration files can be input manually e Third Part Gateway Interface For extension of other standard gateway interface this interface can be extended by the future developer which provides a flexible interface to other Wireless Sensor Management Services and Applications Platforms 4 4 H WSNMS Implementation 4 4 1 H WSNMS Software Architecture Overview A three layer Architecture based on J2EE Frame is applied in the design of H WSNMS Service Comprehensive Application Platform Figure 4 6 displays H WSNMS Software Architecture 34 J2EE Architecture Service and Application Users JSP Presentation Layer WSNs Service Logic Gateways DB aee Figure 4 6 H WSNMS Software Design Service Logic Layer is responsible for the implementation of all logical functions in the whole management system which is designed by Java Technology JSP Presentation layer is responsible for the implementation of all Web pages such static User Interfaces and other dynamical web pages
80. ure is very helpful in solving the issues in the design of the management system The integration efforts are minimized by hiding much of the implementation details and exposing only the functionality of the WSN in use The management also is simplified because the logic is encapsulated in services with a manageable granularity The services can be deployed removed or upgraded from a central location to adapt the system to the business requirements In this thesis we focus on the integration of various WSN platforms for management and operation purpose SOA architecture based on Web services technology recently have become popular for building complex yet flexible enterprise Web based Management Systems CHAPTER 3 H WSNMS ARCHITECTURE 3 1 H WSNMS System Framework Overview H WSNMS is structured on various Wireless Sensor Networks hiding the heterogeneity of WSNs and providing a basic WSN Service Management platform to web based WSNs Service and Application Users This kind of platform should satisfy three aspects e Open multi function access oriented services system the platform adopts an open system architecture and technology scheme In this platform the division of function entities distribution of service functions and corresponded interface should abide by open standard e Unify service support environment e Improve service search and generic fame component according to the requirement Quick deploy new services Based on
81. wing two sections we will discuss the Clients Tier and Gateway Tier respectively 5 2 1 Client Tier The Client Tier provides the user visualization software and graphical interface for managing the network and retrieving sensor data In H WSNMS system we can directly acquire data through accessing Wireless Sensor Network which is an advantage displayed in the function Data Collection Function and manage the heterogeneous wireless sensor networks which is another advantage described in several familiar functions in the wireless sensor networks management such as Monitoring Configuration Reprogram 46 and Data Collection and so on In H WSNMS Client Tier is designed and implemented with JSP and JavaScript Technologies 5 2 2 Specific Gateway Middleware The Gateway Tier is an always on facility that handles translation and buffering of data coming from the wireless network and provides the bridge between the wireless motes and the web based Applications In this Case XServe is a specific gateway middleware as described in Figure 5 3 wherein XServe and XOtap are server layer applications that can run on a PC or Stargate Crossbow XServe 7 is the glue layer that connects the wireless sensor network to enterprise or industrial networks through standard XML Due to the low power and memory footprint requirements in wireless sensor networks communication is streamlined through message formats and network protocols A loc
82. xc converted tos packets exported to file export converted db parsed tos packets exported to db database parsed dbserver database server name default localhost dbport database server port number default 5432 dbname database name default MoteView db dbuser database user default MoteView user dbpasswd database user password default MoteView user password parsed tos packets exported to db deprecated database parsed xmlr raw tos packets exported to xml xml raw xmlp parsed tos packets exported to xml xml parsed xmlc converted tos packets exported to xml xml converted xmifile file name to store exported xml default screen xmlport port number to start the xml server v show version of all modules h display data through web server m export data using modbus port set server port lt default 9001 gt sf connect to unframed serial forwarder fsf connect to framed serial forwarder device connect to serial device lt default dev ttySO gt baud set serial baud rate lt default 57600 gt platform set platform lt default mica2 gt values mica2dot mica2 mica telos micaz debug set debug level lt default DBG VWARNING gt alert alert when data values are above below specified ranges daemon run in daemon mode 80 nomonitor run without a system monitor configfiles load xml configuration files loadparsers load only the listed p
83. y Management for Sensor Networks in the Presence of multiple Applications In Proc IEEE PERCOM Conf Mar 2003 L B Ruiz 1 G Siqueira L B e Oliveira H C Wong J M S Nogueira and A A F Loureiro Fault Management in Event Driven Wireless Sensor Networks In Proc ACM MSWIM Conf Oct 2004 W L Lee A Datta and R Cardell Oliver WinMS Wireless Sensor Network Management System an Adaptive Policy based management for Wireless Sensor Networks Tech Rep UWA CSSE 06 001 The University of Western Australia June 2006 C Hsin and M Liu A Two Phase Self Monitoring Mechanism for Wireless Sensor Networks Journal of Computer Communications special issue on Sensor Networks vol 29 no 4 2006 pp 462 476 T H Kim and S Hong Sensor Network Management Protocol for State Driven Execution Environment In Proc CUC Conf Oct 2003 H Cha and I Jung RMTool Component Based Network Management System for Wireless Sensor Networks In Proc 4th Consumer Communications and Networking Conf 2007 pp 614 618 G Tolle and D Culler Design of an Application Cooperative Management system for Wireless Sensor Networks n Proc 2th European Workshop on Wireless Sensor Networks EWSN Istanbul Turkey January 2005 P J Marron A Lachenmann D Minder J Hahner R Sauter and K Rothermel TinyCubus A Flexible and Adaptive Framework for Sensor Networks In Proc 2th Europ Workshop on Wireles
84. y help help p parsed display of tos packets parsed c converted display of tos packets conveted v show version of all modules port set server port lt default 9001 gt sf connect to unframed serial forwarder fsf connect to framed serial forwarder device connect to serial device lt default dev ttySO gt baud set serial baud rate lt default 57600 gt platform set platform lt default mica2 gt values mica2dot mica2 mica telos micaz Table B 7 XOtap Command Arguments Command interface Description Sne Bante if the voltage is above the threshold default 2 7v p lt image number gt Boot the image number So Sf lt ip port gt XServe host port default to localhost 9001 c lt COM port gt Serial port if connected directly eg c COM1 motelD motelD List the Motes to download or check status Note The above parameters referring the XServe Manual and Mesh Manual provided by CrossBow Mote Works 83 84 Appendix C Table C 1 Monitoring ServicelD Definition H Monitoring VCS NXXY10 extendable 105110 H_Monitoring Monitoring WSN xserve S COM5 b 57600 Table C 2 Configuration ServicelD Definition H Config ReConfig VCS NXXY20 NXXY39 extendable ServicelD Description 105121 H Config Reconfig GID set default group lt group id gt 105122 H Config Reconfig GetlD get config lt destination address gt 105123 H Config Reconfig Se

PURDUE UNIVERSITY

Contents

Download Pdf Manuals

Related Search

Related Contents