Lab I – Surface Water Detection System Description
Running head:
Lab I – Surface Water Detection System Description
Lab I – Surface Water Detection System Product Description
Eric Boyd
CS411
Professor G. Price
March 21, 2011
1
Lab I – Surface Water Detection System Description
2
TABLE OF CONTENTS
1
INTRODUCTION ...................................................................................................................5
2
SWDS PRODUCT DESCRIPTION ........................................................................................6
3
2.1
Key Product Features and Capabilities .............................................................................6
2.2
Major Components (Hardware/Software) .........................................................................8
2.3
Target Market/Customer Base ..........................................................................................9
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]
Lab I – Surface Water Detection System Description
3
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]
Lab I – Surface Water Detection System Description
4
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
5
INTRODUCTION
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.
Lab I – Surface Water Detection System Description
2
2.1
6
SWDS PRODUCT DESCRIPTION
Key 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]
Lab I – Surface Water Detection System Description
Figure 1. Technical Overview
Because sensor measurement data is constantly recorded over the network, and in realtime, 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]
7
Lab I – Surface Water Detection System Description
2.2
8
Major Components (Hardware/Software)
Figure 2. Hardware Component Diagram
Remote Device
Development PC
Data
Acquisition
Client
Data
Acquisition
Host
Control
Software
Database
User
Applications
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
Lab I – Surface Water Detection System Description
9
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.3
Target 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 higherlevel of highway safety for their drivers, lower costs in recouping property damages and public
Lab I – Surface Water Detection System Description
10
services rendered, and the ability to charge fees for historical data provided to insurance
companies for third-party law suits.
3
SWDS 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.1
Prototype 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
Lab I – Surface Water Detection System Description
11
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]
Lab I – Surface Water Detection System Description
Figure 4. City User GUI
Figure 5. Insurance Agency GUI
12
Lab I – Surface Water Detection System Description
13
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]
Lab I – Surface Water Detection System Description
3.2
14
Prototype Architecture
Roadside
Warning Sign
Remote Device
Ultrasonic
Sensor
Embedded
Microcontroller
Internal Data
Store
Data Center
Web Server
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]
Lab I – Surface Water Detection System Description
Feature
Real World Implementation
Sensor
Microcontroller
15
Prototype
One sensor available for closed system;
Will feature one sensor that
multiple sensors for networked system.
detects and sends data to the
Ruggedized housing to protect from the
simulation computer in the
elements.
closed system demonstration.
For closed system, embedded data store and
Will feature one
algorithms to throw out erroneous data. For
microcontroller that receives
networked solution, programmed to send
data from a single sensor and
data to centralized data center.
sends it to the development
PC.
Multi-Sensor
If client chooses to implement networked
This will be simulated for the
Network
solution, this is available for
networked demonstration.
implementation. The number of sensors will
be determined by the client based upon
several factors.
Centralized Data
Data collection server that stores the info
Will be simulated.
Center
from the microcontroller
Report Generator
Users can access reports from the product
This is simulated in a GUI on
website which will feature an administrative
the development computer.
login for clients. The data is pulled from a
database on the server.
GoogleMaps™
Featured on the product website with real-
Will be simulated on the
application
time water depth measurements in inches.
product website via a GUI.
RSS
Included on the product website for entities
An icon will be featured on
to subscribe.
the product website but will
not be functional.
Table 2. Prototype vs. Real-World Implementation Comparison
Lab I – Surface Water Detection System Description
16
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.
Lab I – Surface Water Detection System Description
17
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.
Lab I – Surface Water Detection System Description
3.3
18
Prototype 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 costeffective, 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.4
Prototype 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 filteringalgorithms 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.
Lab I – Surface Water Detection System Description
19
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.
[This space left intentionally blank]
Lab I – Surface Water Detection System Description
20
GLOSSARY
Algorithm: A precise rule or set of rules specifying how to solve a problem.
Annual software license: A legal contract governing the usage of software that is updated once
a year.
Application Programming Interface (API): Software implemented to allow for simpler and
more abstracted interactions with other software.
Baseline package: The basic closed-system version of the flood detection system that includes
the ultrasonic sensor, microcontroller, ruggedized housing, and flashing warning sign.
This is best suited for remote locations where a sensor network would be impractical
Bid proposal: An explanation of products and services given with an estimated cost.
Centralized data center: The software and hardware that acts a central point for collecting the
sensor data transmissions over a network and recording their values into a database.
Client: Any end-system that is connected to a network.
Closed system: A single ultrasonic sensor, microcontroller, ruggedized housing, and warning
sign set up that has no network interface.
Commercial front-end: An entity that provides some means, via website or physical location, to
sell a product. These are direct whose primary goal is to sell its company’s deliverables to
a targeted market.
Embedded data store: The ability to store data on the microcontroller.
Flooding: An inundated area of roadway that is considered impassible due to an influx of water.
Global Positioning System (GPS): A navigational system that pinpoints latitude and longitude
of a location using stationary satellites.
Google Maps API: A technology created by Google that utilizes maps to support a variety of
Lab I – Surface Water Detection System Description
21
uses, typically displaying related locations in map form through a web browser.
Graphical User Interface (GUI): A user-friendly interface that allows easy access to an
applications features, which uses a mouse and keyboard as input devices.
Microcontroller: A small computer on a chip that is used to control electronic devices.
Modularized: Development technique which involves breaking a unified process or idea into
coherent segments for the purpose of abstraction or simplicity.
Multi-sensor network: Several sensor installations connected by a network infrastructure that
relay measurements back to a centralized data center.
Network: A system of interconnected electronic components or circuits.
Prototype: Logical step in the development process demonstrating the real world potential of a
concept.
Real time data: Information that is collected in the actual time the process is occurring.
Really Simple Syndication (RSS): Formatted XML used to provide subscribers with
information updated on a regular basis.
Risk analysis: Identifying and assessing factors that may compromise the success of a project.
Ruggedized housing: An enclosure designed to protect an electronic device such as a field
sensor from the elements.
Server: A computer used to accept incoming requests and information over a network, and inturn, generates and transmits data back to another user or computer (client).
Ultrasonic sensor: A sensor that calculates changes in depth using high frequency sound waves.
User base applications: Programs developed for the purpose of providing services to users.
Warning sign: A type of traffic sign that indicates a hazard on the road that may not be readily
apparent to a driver.
Lab I – Surface Water Detection System Description
Web Server: A computer that delivers content from websites over the internet.
22