A Distributed Framework for Remote Monitoring of ... - Semantic Scholar

A Distributed Framework for Remote Monitoring of Hurricane Wind Pressures and Wind Speeds using Wireless Sensor Networks C. Otero1, I. Kostanic1, C. Subramanian2, J.P. Pinelli3, and A. Velazquez3 Electrical & Computer Engineering, Florida Institute of Technology, Melbourne, FL, USA 2 Mechanical & Aerospace Engineering, Florida Institute of Technology, Melbourne, FL, USA 3 Civil Engineering, Florida Institute of Technology, Melbourne, FL, USA 1

Abstract - This paper presents a generalized software architecture used in a real sensor network application to provide the necessary communications infrastructure between remote sensor units and centralized server. The architecture utilizes existing wireless networking standards (IEEE 802.11 and HSDPA) and relies heavily on built in capabilities of Microsoft .NET development framework. Through layered and object oriented design the architecture achieves high degree of modularity, reliability and code maintainability. Although developed for specific application scenario, the architecture may be easily adopted for wide variety wireless sensor network application scenarios. Keywords: Wireless sensor networks, hurricane monitoring, .NET, wireless networking.

1

Introduction

Recent advances in micro electro-mechanical systems (MEMS) have led to the development of small, radio-enabled, sensor-enabled, and low-power computers that are capable of sensing the world and communicating with each other. Such computer nodes may be deployed in various configurations that form wireless sensor networks (WSN). Wireless sensor networks promise to change the way we live. Some applications for WSN include military applications, wearable devices, home applications, security, and environmental monitoring among others. A typical wireless sensor network includes a set of communicating nodes that are tasked with sensing the environment and communicating with each other to transmit the information back to a base station. From the base station, the information is usually relayed to a central location where it is processed and analyzed. Much of the research in WSN has been devoted to in-network communications techniques that minimize the power consumption of sensor devices, increase the communication efficiency and extend the network lifespan. However, much of the applicability of WSNs will be determined by how well they can disseminate the collected data across remote sites. Therefore, it is equally important to develop communication

frameworks that can easily integrate sensor networks with remote back-end, where data can be processed and from which the sensor network can be managed. This paper describes a generalized communications architecture implemented using tools available within Microsoft’s .NET Framework. The architecture provides a communication back-end for a sensor network designed to monitor several parameters associated with hurricane winds and their impact on man made structures [1]. The communications back-end is tasked with data transfer from the deployed base station and sensor units to a remote server which provides data processing and system monitoring capabilities. A brief summary of the system is followed by a detailed description of the software architecture. Finally, this paper addresses areas of improvements and future work that will permit accommodation of different applications scenarios using the described communication architecture.

2

System Description

An overview diagram of the sensor network for the hurricane characterization is presented in Figure 1 [1]. As seen, the overall network consists of three major subcomponents. The first sub-component comprises of many remote sensor units and associated base unit that are installed on the structure under measurement. This sub-component is referred to as the house installation and it is responsible for performing measurements and data acquisition. The wireless communication protocol between sensor units and base station is a custom designed protocol that optimizes the utilization of available bandwidth and power resources. The second subcomponent is the communication network connecting individual house installations to a central server. Finally, the third component is the central server itself, which processes measured data and enables network operator to control the actions of the base and sensor units.

3.1

Software Architecture and Design

An overview of the software architecture for the hurricane monitoring system is presented in Figure 2. The software has been designed using layered architecture [3].

Figure 1 – System Description There are two ways in which the house installation may be linked to the server. The first one is using IEEE 802.11 (WiFi) connection. If the monitored house is equipped with the wireless Internet, the laptop connected to the base station utilizes the wireless Internet connection to provide a link to the central server. Alternatively, for house installations where there is no availability of 802.11 networks, the connection to the central server is provided through a cellular data network. In the particular case of the hurricane monitoring network described in [1], the connectivity through cellular network is accomplished with an UMTS/HSDPA/HSUPA card [2]. This card provides theoretical uplink (i.e. from base unit towards server) data throughput of 5.76Mbits/sec. However, in practical scenarios, the achievable throughput is limited by coverage, signal quality and the overall data traffic demand placed on the cellular network in the deployment area. In most cases, a throughput of several hundred Kbits/sec to 1.5Mbits/sec is easily achieved. Two wireless networks provide redundant connections. By default, the sensor network is connected using the 802.11 interface. However, in the case of power outage on the house or in the case when the 802.11 connection is not available, HSUPA provides a seamless alternative to the 802.11 connection.

3

Software Description

The communication software utilized for transfer of measured data from the house installation to the end user is composed of three segments, namely: Collection Segment, Data Processing Segment, and Client Segment. The Collection Segment is designed to interface with the base unit of the sensor network. Its responsibility is to compress and forward data to the Data Processing Segment. The Data Processing Segment is designed to decompress, process and analyze measured data. Upon analysis, it provides data (for presentation purposes) to the Client Segment. The Client Segment’s main purpose is to handle the interface to the operator through a convenient web interface. It allows operator to access the server and processed data from anywhere across the Internet.

Figure 2 – Software Architecture This architecture clusters similar operational tasks into layers which ultimately result in modular and reusable software. The layering of components also allows minimization of the dependencies between components and controls the way the software interacts as a whole. Using this approach, components can be added or removed at different layers without impacting the other layers. The layers presented in Fig. 2 are: User Layer, Manager Layer, and Communications Layer. At each layer, the .NET framework is used to facilitate the necessary tasks required for processing and transfer of the data to the remote site. The following architectural rules are implemented: • The User Layer can only communicate directly with the Manager Layer. It cannot communicate directly with the Communications Layer. • The Manager layer can communicate directly with both the User Layer and Communication. Layer.

• The Communication Layer can only communicate directly with the Manager Layer. It cannot communicate directly with the User Layer.

3.2

User Layer

The User Layer is responsible for all aspects of the visualization of the data in the system. This layer is necessary to separate the processing and communication of the system from the visuals. User interfaces can include Graphical User Interfaces, Console, or Web User Interface. All user interface objects derive from the UserInterfaceObject, which provides the behavior necessary to communicate with the Manager layer via a single unified interface.

3.3

Manager Layer

The manager layer is where all logic and processing is orchestrated. The main functions managed at this layer are compression, events, and file system common tasks. The manager layer delegates all visualization aspects to the user layer, and also delegates all details of communication to the communication layer. The hurricane monitoring system uses the following managers: • FileSystemManager: Handles all operations dealing with the file system (e.g., file creation, copy, and path monitoring) • CompressionManager: Handles all the operations needed to compress data.

Another characteristic of Manager Objects is that they are designed as Singletons [4]. The Singleton Design Pattern is used to control the number of instances that a class can have at runtime. By creating each manager as Singletons, user layer objects are assured that they can interface with the right manager instance when necessary. The main contribution that the manager layer design approach provides is that new capabilities can be added to the system without affecting any other part of the software, simply by adding new managers to the manager layer. Future capabilities to the system such as CryptoManager and SecurityManager can be simply added as new managers. Each manager, whether currently existing or newly added, will always be independent from all other managers and from the other layers in the software architecture.

3.4

The communications layer is responsible for handling the details of each communication protocol for successful data transmission. Objects in this layer can be added to support different communications alternatives such as TCP and UDP sockets. Essential to this layer is the CommFactory object which provides access to each object available in this layer. This way, there are no direct dependencies between manager objects and specific communication objects, thus resulting in a controlled cross-layer communication environment. This mechanism gives the architecture the ability to swap communications objects without effort to change the overall behavior of the system. For this system, the following communication object has been identified:

• EventManager: Handles all events that occur in the software. All Manager Layer objects derive from a Manager base class. The Manager base class provides to all derived classes the ability for external clients to register (with any derived manager) for asynchronous cross-layer communication. This capability is essential when communicating with User Layer objects. With this approach, user interface objects can register with any manager to receive data asynchronously. This behavior is known as the Observer Design Pattern [4]. Designing and implementing the Observer pattern using C/C++ can be a challenging and error prone task. Due to the nature of the pattern, it is very easy to overlook an implementation detail that can result in software defects such as buffer overruns or memory leaks. Also, by implementing the observer pattern using C/C++, the amount of code required to test and maintain is greater. In the implementation discussed in this paper, The Manager Layer leverages native .NET capabilities to obtain the behavior of the Observer pattern. The .NET’s built-in observer capabilities are easy to use and the amount of design and development effort is reduced. Also, by relying on .NET’s built-in garbage collection, memory leaks are not an issue.

Communication Layer

• FtpClient: This communication object handles all the operations necessary to transfer data to a remote server using the File Transfer Protocol.

4

Framework Implementation

With the software architecture defined, it is easy to embed capabilities into the appropriate layer of the software. The major capabilities identified are all native to the .NET framework, which greatly facilitates the software implementation. The following sections describe the .NET capabilities used in this system.

4.1

FileSystemWatcher

A typical sensor network contains a special node with greater computational capabilities where data is sent for processing or forwarding to remote locations for processing. This special node is referred to as the sink [5]. In the hurricane monitoring network, the sink is the laptop, which is responsible of gathering data and forwarding it across the Internet. Wind characterization data from the sensor nodes is collected at the sink and deposited in an outgoing directory that is monitored by the Collection Segment client software.

Typically five minutes of data collection is deposited as a single measured data file. Each new data file is detected by the client software and transferred to a remote server. In traditional development environments, using C/C++, one would have to periodically monitor this directory for changes and react to file system changes. With this approach, you can either scan the directory using short or long intervals. Using short intervals can be proven to be inefficient, as it wastes computer resources at a quicker rate even if no files have been added to the file system. Using longer intervals would increase the time to react; therefore data could be idle in the directory waiting for the next scan cycle. This would hinder the communication efficiency of the system. The .NET framework introduced a component that resolves all the issues involved in forwarding wind characterization data. The FileSystemWatcher is a native component that resides in the System.IO namespace. It transforms an otherwise tedious and error prone task into a seamlessly efficient software routine. The FileSystemWatcher component allows developers to register a file system path with the software to monitor the path for any changes. The registration phase requires the use of a call-back routine that gets called whenever a file system change is detected. It is in this callback routine that the software application reacts to changes made to the file system. Once a change is detected, the .NET framework ensures that the call back method receives the information needed by passing it arguments that describe attributes such as type of file system change (i.e., file created, deleted, etc.) filename, path, etc. This information is essential for future compression and transfer of the data. The hurricane monitoring system relies on the FileSystemWatcher to detect new data files collected by the sensor network. Once new sensor data is acquired, it is compressed at the manager layer and sent to the communication layer for transfer. The FileSystemWatcher is a great example of how the .NET built-in capabilities provide superior alternatives to traditional C/C++ approaches.

4.2

would be to have built in programmable capabilities to compress data. The .NET Framework included the Compression component in the 2.0 release. The compression component resides in the System.IO.Compression namespace and allows developers to programmatically compress and decompress using the GZIP format, which uses a broadly accepted algorithm for compression and decompression. It is important to document that although the built-in .NET compression tools are very convenient, they do not come without efficiency penalties. It has been observed through experimentation that popular compression methods, such as the .zip format perform better as the size of the compression data increases. Also, through experimentation, it was noticed that the time for compression is less when using the .zip format. Table 1 reports the results of compressing several ASCII files for both the .NET compression format and the .zip format: Table 1 – Comparison between .NET built-in compression and standalone ZIP compression File

Original

ZIP Compressed

.NET Compressed

1

10 KB

1KB

1KB

2

100KB

2KB

2KB

3

1000KB

10KB

19KB

4

5000KB

46KB

94KB

5

10000KB

91KB

188KB

6

20000KB

181KB

376KB

7

40000KB

362KB

752KB

8

80000KB

724KB

1500KB

Compression

As seen in Fig. 1, current implementation of the hurricane monitoring system uses wireless LAN or a bandwidth-limited cellular network as the transport mechanisms for the wind characterization data. To achieve efficient use of the wireless bandwidth, the measured data is compressed before over the air transmission. There are several compressions algorithms available. Familiar compression tools such as .zip are common, but are not natively available for programmatic interface using C/C++. Several techniques to add .zip support include spawning a separate process that would rely on the zip.exe application to zip an existing directory. Although this approach works, it is by far not the most desirable approach. The main reason is that there is no feedback between the process created and the application that creates it. This independence prevents the main application from reacting to any errors in appropriate manner. This could have a significant negative effect in remotely operated software. Therefore, a better approach

It can be seen that the compression algorithms have similar efficiency when the data is less than 100KB. After 100KB the increased compression efficiency of the .zip format is evident. The hurricane monitoring system does not experience much of the .NET compression inefficiency because it is designed to transfer 5 MB of data every 5 minutes. After compression this results in approximately 94Kb of data every five minutes and it is easily handled by either one of the two wireless networks.

4.3

FTP

The File Transfer Protocol (FTP) is an application layer protocol that executes on top of the TCP/IP suite. This means that in order to add FTP capabilities to a software application,

the application must have the capability to communicate via TCP/IP (e.g., windows sockets) and the FTP protocol must be implemented. In traditional languages such as C/C++ there is no built-in object that encapsulates a windows socket. Software developers usually create their own by encapsulating the WinSock system calls provided by the Windows operating system. This is a time consuming task whose implementation usually requires a high level of expertise. Additionally, C/C++ developers usually are required to implement the FTP protocol to add its functionality to the software application. When using the .NET framework, the requirements for development of custom socket objects and FTP objects are completely gone. The .NET framework provides native support for both TCP/IP and FTP capabilities. By leveraging on the .NET framework, adding FTP capabilities to the software architecture framework was trivial. The FtpWebRequest object, which resides in the System.Net namespace, provides the capabilities to easily implement reliable FTP clients without the effort required in traditional languages such as C/C++.

5

Benefits of Software Architecture

The main benefits achieved by the described software architecture are two fold. First, the architecture provides for easy additions of new capabilities to the system. These additions can be in a form of new user interfaces, new processing tasks, or new communication protocols. By embedding well known object oriented design patterns into the architecture, the software has a high level of modularity, which results in reusable and easily maintainable code. Second, by leveraging on Microsoft’s .NET framework, the hurricane monitoring system employs a relative small amount of code to add capabilities that would have made the software more complex and error prone if done with an older language such as C or C++. Additionally, by using the .NET framework, it is expected that the architecture will be more resilient to common software errors such as memory leaks.

6

Future Work

Although the software architecture described in this paper performs adequately for the task at hand, there are several avenues for its improvement. Some of the possible improvement directions are listed as follows.

6.1

Encryption

Security issues in network communications can be the most important requirement for some remote wireless sensor network applications. For this reason, the software architectural framework must include cryptographic support to fit the needs of these applications. Cryptography may be one of the most challenging tasks for software developers, since it requires knowledge of advanced encryption algorithms. Native to the .NET framework is the

System.Security.Cryptography namespace which includes tools to facilitate the process of providing security to software applications via encryption. Future versions of the architecture presented in this paper could benefit from a CryptoManager object that resides in the Manager Layer and handles all aspects of encryption and decryption when communicating across remote sties.

6.2

Support for Common Protocols

Different applications have different communications requirements. Addition of different Communication Layer objects that handle protocols such as TCP and UDP sockets, HTTP, serial and USB communication would make the architectural framework more generalized and adaptable to different applications.

6.3

Security Authentication

Additional security can be added to the software by adding a SecurityManager object that authenticates users before a software operation can be performed. For example, before reacting to file system events, the FileSystemManager could consult with the SecurityManager object to validate the operator’s credentials in order to authenticate the user. This way, security can be enhanced at the remote site.

6.4

Conclusion

We have presented a generalized software architecture that is used in a real sensor network to provide the necessary communications infrastructure between remote sensor units and centralized server. Although applied towards a specific application, the software architecture can be used to remotely monitor any sensor network application. This architecture is highly scalable and it relies heavily on native .NET components for interlayer operational tasks and on industry standard object oriented design patterns for cross-layer communication. These characteristics allow the software to easily carry out common software operations inside layers, while remaining open to new capabilities that can be added with a relatively little programming effort.

7

Acknowledgements

The research reported in this paper is supported by the NSF grant CMS-0625124. This support is gratefully acknowledged.

8

References

[1] Kostanic, I., Subramanian, C.S., Pinelli, J.-P., Buist, L., Velazquez, A., and Wittfeldt, A., “Monitoring of Hurricane Wind Pressures and Wind Speeds on a Residential Home Roof with Wireless Instrumentation,” in proceedings of Structural Engineering Congress, Vancouver, Canada, April 24-26, 2008.

[2] Holma, H., Toskala, A., HSDPA/HSUPA for UMTS, John Wiley and Sons, LTD., 2006. [3] Buschmann, F., Meunier, R., Rohnert, H., and Sommerlad, P., “Pattern-Oriented Software Architecture Volume 1: A System of Patterns”, Wiley, 1st edition, 1996. [4] Gamma, E., Helm, R., Johnson, R. and Vlissides, J.M., “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley Professional Computing Series, 1994. [5] Akyildiz, I.F., Su, W., Sankarasubramaniam, Y., Cayirci, E., “Wireless sensor networks: a survey”, Computer Networks 38 (4) (2002) 393–422.