Lab I – Surface Water Detection System Description 1
Running head: Lab I – Surface Water Detection System Description
Lab I – Surface Water Detection System Product DescriptionEric Boyd
CS411
Professor G. Price
March 21, 2011
Lab I – Surface Water Detection System Description 1
TABLE OF CONTENTS
1 INTRODUCTION...... 5
2 SWDS PRODUCT DESCRIPTION...... 6
2.1 Key Product Features and Capabilities...... 6
2.2 Major Components (Hardware/Software)...... 8
2.3 Target Market/Customer Base...... 9
3 SWDS PRODUCT PROTOTYPE DESCRIPTION...... 10
3.1 Prototype Functional Goals and Objectives...... 10
3.2 Prototype Architecture...... 14
3.3 Prototype Features and Capabilities...... 18
3.4 Prototype Development Challenges...... 18
GLOSSARY...... 20
[This space left intentionally blank]
LIST OF FIGURES
Figure 1.Technical Overview...... 7
Figure 2.Hardware Component Diagram...... 8
Figure 3.Software Component Diagram...... 8
Figure 4. City User GUI...... 12
Figure 5.Insurance Agency GUI...... 12
Figure 6.Public User GUI...... 13
Figure 7.Major Functional Component Diagram...... 14
[This space left intentionally blank]
LIST OF TABLES
Table 1.Competition Matrix...... 10
Table 2.Prototype vs. Real-World Implementation Comparison...... 15
[This space left intentionally blank]
Lab I – Surface Water Detection System Description 1
1INTRODUCTION
Metropolitan areas and their inhabitants are in a constant battle against flash-flooding caused by uncontrollable conditions such as heavy rain fall and storm surges combined with regularly occurring tidal forces. Often these conditions come on with little or no warning, and predicting exactly what areas will be affected is extremely difficult. Drivers and their vehicles are often the first to encounter these hazardous conditions.
One of the biggest challenges drivers face when these conditions are present, is estimating their vehicle’s ability to pass an inundated stretch of roadway. Often, a driver is navigating through only a couple of inches of water, and then suddenly finds themself in over their head. Whether situations like these are caused by gross negligence, or are truly accidental is hard to determine. In either case, the Surface Water Detection System aims to mitigate the resulting property damages and personal injury.
The Surface Water Detection System (SWDS) is a simple warning system that alerts drivers to impassible sections of roadway caused by inundations of water. The warning is produced by a roadway warning sign with flashing lights at the exact location of the inundation. The flashing lights are triggered by a nearby device that measures the depth of the water, and actuates the warning sign based on a configurable threshold depth.
In addition to being able to alert drivers with a warning sign at a particular location, the SWDS uses contemporary technologies like high-speed computer networks and the World Wide Web to deliver a host other alert mechanisms for today’s tech savvy drivers such as interactive web maps and customized alerts than can be sent to mobile devices.
2SWDS PRODUCT DESCRIPTION
2.1Key Product Features and Capabilities
The SWDS uses an ultrasonic sensor to measure water depth installed at a location that is prone to flooding caused by heavy rains or tidal forces. Often, city or state jurisdictions opt to place a ruler, sometimes painted on the walls of an underpass, to help drivers gauge and realize the depth of the water at the section of road they are confronted with. These measurement guides are not obvious and do not do enough to warn drivers that there is imminent danger. The ultrasonic sensor of the SWDS triggers a warning sign equipped with bright flashing lights to alert the driver to the danger. The lights are triggered once a configurable threshold depth is met, and remain active until the water level recedes below the threshold.
The SWDS was designed to be used in two different configurations. The first configuration, referred to as the “closed-system”, includes the ultrasonic sensor, the warning sign, flashing lights, and necessary hardware and software to control the sensor and lights. The second configuration, referred to as the “networked-system”, allows any number of sensors and related hardware to be networked together, and controlled by a centralized data center. This centralized control allows jurisdiction operators to monitor and remotely configure sensors, and query a centralized database that stores sensor measurement data recorded from the sensors over the network. Figure 1 illustrates this technical overview of the SWDS, and where the distinction between the closed-system and networked-system is drawn.
[This space left intentionally blank]
Figure 1. Technical Overview
Because sensor measurement data is constantly recorded over the network, and in real-time, the SWDS can deliver public web services including a website that users can access for real-time updates to water depths in the jurisdiction. These updates include, but are not limited to: a “news feed” that provides up to date warnings for hazardous locations in the jurisdiction, interactive maps that use geo-location services that provide the real-time status of sensors in the jurisdiction, and the ability for users to create a customizable alert that includes only those sensors they are concerned with.
[This space left intentionally blank]
2.2Major Components (Hardware/Software)
Figure 2. Hardware Component Diagram
Figure 3. Software Component Diagram
Figures 2 and 3 illustrate the major functional hardware and software components of the SWDS design. The first major component is the remote device which houses the ultrasonic sensor, embedded microcontroller, and the device’s internal data store.
The second major functional component is identical to the remote device in every aspect, except that the device’s network interface is taken into account. The network interface of the remote device enables the device to communicate its sensor measurement data over a network infrastructure to a centralized data center, and receive communication, such as configuration settings, from the data center.
The next component is the centralized data center which acts as a network hub for all of the remote devices on the network. The data center receives sensor measurement data from the remote devices, and redirects that data to a centralized database. In addition, operators at the data center can configure the remote devices by updating a configuration table in the centralized database, and query the centralized database for historical sensor measurement data.
Lastly, a public web server is in place that hosts the various end-user applications such as a public website with alerts and interactive maps, and the customizable alert system.
2.3Target Market/Customer Base
The SWDS product is marketed toward municipal jurisdictions such as city or state governments, especially those which include low-lying areas, or areas prone to flash-flooding. It is difficult to estimate the total cost jurisdictions incur over a given timespan handling vehicular damage and personal injuries resulting from vehicles becoming stuck or submerged in inundations of water. These situations may involve law suits, vehicle insurance companies, hospitals and ambulance services, towing companies, and any costs needed to repair private or government property.
These jurisdictions, especially those with frequent flooding problems, have an obligation to keep their drivers safe, and to provide adequate warning to dangerously high water levels. The SWDS is designed as a supplementary warning system to a jurisdiction’s existing warning mechanisms. The added benefit to these jurisdictions include, but are not limited to: a higher-level of highway safety for their drivers, lower costs in recouping property damages and public services rendered, and the ability to charge fees for historical data provided to insurance companies for third-party law suits.
3SWDS PRODUCT PROTOTYPE DESCRIPTION
The prototype design of the SWDS demonstrates all of the core capabilities and components of the overall commercial SWDS design. The major differences will be covered in the following sections.
3.1Prototype Functional Goals and Objectives
The first functional objective of the prototype is to successfully demonstrate the ability to use an ultrasonic sensor to measure water depth. Existing means of gauging water depth involve underground sensors that measure the pressure of the water above it. These installations are cumbersome and expensive, and the SWDS prototype will demonstrate that an above-ground mounted ultrasonic sensor, allows for a more flexible and easy installation. Table 1 highlights some of the differences between the SWDS design, and some competing technologies.
Table 1. Competition Matrix
The second objective is to demonstrate that filtering-logic, embedded on the prototype remote device, can successfully determine what the true depth of a body of water is. Moving traffic, obstructions caused by roadway debris and animals, and any other erroneous readings must be filtered-out if the above-ground ultrasonic sensor design of the SWDS is to be proven effective.
The third objective is to demonstrate that multiple remote devices can be networked, and manipulated from a centralized location. This will involve demonstrating remote devices transmitting their sensor measurement data over the network to a centralized database, and the ability to configure remote devices over the network.
The fourth objective is to demonstrate a mock-up of the centralized data center, and the user interfaces necessary to monitor and configure remote devices over a network, and to query the centralized database for historical sensor measurement data.
[This space left intentionally blank]
Figure 4. City User GUI
Figure 5. Insurance Agency GUI
The fifth and final objective will demonstrate a mock-up of the public web server, and the various public services it provides. This will include demonstrating a news feed that is configurable over the network from the centralized data center, an interactive map that displays the real-time status of the remote devices, and the ability to configure and receive customized alters that are configurable by selecting which remote sensors to include in the alert.
Figure 6. General Public GUI
[This space left intentionally blank]
3.2Prototype Architecture
Figure 7. Major Functional Component Diagram
Figure 7 illustrates the major functional components of the SWDS prototype. It provides a higher-level view of the overall SWDS architecture than is depicted in the hardware and software component diagrams (Figures 2 and 3 in Section 2.2). Table 1 highlights the differences between the prototype and real-world implementations.
[This space left intentionally blank]
Feature / Real World Implementation / PrototypeSensor / One sensor available for closed system; multiple sensors for networked system. Ruggedized housing to protect from the elements. / Will feature one sensor that detects and sends data to the simulation computer in the closed system demonstration.
Microcontroller / For closed system, embedded data store and algorithms to throw out erroneous data. For networked solution, programmed to send data to centralized data center. / Will feature one microcontroller that receives data from a single sensor and sends it to the development PC.
Multi-Sensor Network / If client chooses to implement networked solution, this is available for implementation. The number of sensors will be determined by the client based upon several factors. / This will be simulated for the networked demonstration.
Centralized Data Center / Data collection server that stores the info from the microcontroller / Will be simulated.
Report Generator / Users can access reports from the product website which will feature an administrative login for clients. The data is pulled from a database on the server. / This is simulated in a GUI on the development computer.
GoogleMaps™ application / Featured on the product website with real-time water depth measurements in inches. / Will be simulated on the product website via a GUI.
RSS / Included on the product website for entities to subscribe. / An icon will be featured on the product website but will not be functional.
Table 2. Prototype vs. Real-World Implementation Comparison
The biggest differences between the prototype and real-world implementations involve simulating much of the hardware needed to create a true, large-scale network infrastructure. Much of the software remains identical in both implementations. Multiple remote devices on a network will have to be simulated due to the cost-prohibitive constraint of purchasing multiple sensors and embedded device platforms.
A program written in C# and running on the Microsoft .Net Compact Framework will reside on the remote device. This program will be responsible for listening to the measurements coming from the ultrasonic sensor, and filtering-out erroneous measurements.
A separate program written in C# and running on the Microsoft .Net Compact Framework will reside on the remote device that allows a technician to configure the remote device. The technician will connect to the remote device via Ethernet cable, and access the remote device’s configuration program using a protocol such as Telnet or HTTP.
In addition to the programs that are used in the closed-system implementation, the remote device will be programmed to act as a networked-sensor if network connectivity is established. If an IP address is specified in the remote device’s configuration file, the remote device will attempt to connect to the IP address on a regular time interval. If the remote device successfully connects to the IP address (this simulates the connection between the centralized data center and a networked-remote device), the remote sensor will routinely request an update to its configuration file, and transmit its sensor measurement data over the network to be recorded in the centralized database.
The second-half of the prototype involves building the software that controls the centralized data center, and the public web server. The centralized data center and public web server will be implemented as web applications writer in C# using the ASP.NET web platform. A centralized database will also be created using Microsoft SQL Server 2008. The centralized database will be accessed by the data center and the public web server to demonstrate the remaining capabilities of the SWDS prototype.
The centralized data center is essentially a website that accesses the database for various things. Incoming sensor measurement data over the network is packaged and stored in the centralized database. This data is then used to display the current status of the remote devices on the network (both the physical prototype and the simulated devices). This data can be queried, using LINQ (Language Integrated Query), for historical purposes. The data in the database, once queried, is displayed to the webpage and possibly can be used to generate various other report formats (Excel, CSV, etc.). The centralized database will also use LINQ to manipulate a sensor configuration table in the database. On regular intervals, the remote device will request an update to its configuration. If a change in the configuration table is found, the data center will package the configuration data, and send it over the network to the remote sensor.
The public web server is a web site that accesses the centralized database for sensor measurement data. This website will create automated alerts on the homepage, updated regularly, when sensor measurement readings are hazardous, or quickly becoming hazardous. In addition, the website will provide an interactive map using the Google Maps API. This interactive map displays all of the sensors in the jurisdiction, their current measurement reading, and their address by using a combination of JavaScript and C#. Lastly, the website allows users to create a customizable alert that. This alert is created by users selecting which sensors they are concerned with (typically those sensors along their daily route). When any of those sensors have reached a hazardous level, the website is responsible for automatically alerting the user.
3.3Prototype Features and Capabilities
Ultimately, the SWDS prototype demonstrates flood-detection using an above-ground sensor, and contemporary technology such as the World Wide Web offers significant benefits over existing technologies with similar objectives. The SWDS prototype demonstrates that utilizing more powerful computer technology versus mechanical-only solutions is not only cost-effective, but offers greater flexibility and capability.
Because internet technology is so easily incorporated into the SWDS design, its demonstration will mitigate any advantages touted by competing technologies that do not offer as flexible or capable solution.
3.4Prototype Development Challenges
There are a few areas of the SWDS prototype design that will present real challenges to its developers. The first challenge will be in correctly identifying the necessary filtering-algorithms to discard erroneous measurements. The main advantage in-ground, pressure sensitive solutions offer, is that water pressure is easy to gauge, and cannot be confused with other debris, or vehicles that may cause erroneous measurements. There are many variables to consider in the filtering-logic, and they must be as accurate and effective as possible to demonstrate that the above-ground, ultrasonic sensor solution is a viable and effective one.
The second challenge will be in identifying the proper risk management strategies that will offer solutions to any technical problems on the network. Identifying what the proper course of action is in case of network-outages will be crucial in demonstrating that a safety device that is so closely tied to a large-scale network is cost-effective and a viable solution to alerting the public to hazardous road conditions.
The last challenge will be the time constraint of implementing the prototype. The overall architecture of the software will have to be established early, and good software engineering practices will have to be used to ensure the product is delivered on-time and in a reasonably operating condition. Likely, the most pertinent features to demonstrate will need to be identified, and those areas of the software development will take precedence over any lesser deemed features. Other aspects of software engineering, such as Software Configuration Management (SCM), will need to be evaluated in terms of the learning-curve for some members of the group, and their overall added value to the project. Test-driven development will also fall into this category. Likely, group members will need to be evaluated on their particular software development experience, and will take on roles according to their level of competency.