Surface Water Detection System (SWDS) Product Description
Running head:
LAB 1 – SWDS PRODUCT DESCRIPTION
Lab 1- Surface Water Detection System (SWDS) Product Description
Jill Mostoller
CS411
Professor Gene Price
Old Dominion University
February 9th, 2011
Version two
1
Surface Water Detection System (SWDS) Product Description
2
Table of Contents
1
INTRODUCTION…………………………………………………………………… 4
2 PRODUCT DESCRIPTION…………………………………………….……………5
2.1
Key Product Features and Capabilities……………….…………………………..5
2.2
Major Components (Hardware/Software)….……………………………………..7
2.3
Target Market/Customer Base…………………………………………………. 11
3 SWDS PRODUCT PROTOTYPE DESCRIPTION……………………………….. 12
3.1 Prototype Functional Goals and Objectives……………………………………...13
3.2
Prototype Architecture…………………………………………………………..14
3.3
Prototype Features and Capabilities……………………………………………..16
3.4
Prototype Development Challenge……………………………………………...18
GLOSSARY……………………………………………………………………………..20
REFERENCES…………………………………………………………………………..23
List of Figures
Figure 1. Technical Overview...…………………………………………………………..6
Figure 2. Hardware Component Diagram..………...……………………………………..7
Figure 3. Major Functional Component Diagram ...…………………………………...…8
Figure 4. Software Component Diagram………………………………………………....9
Figure 5. Insurance Agency GUI………………………………………………………..10
Figure 6. City User GUI………………………………..………………………………..11
Figure 7. General Public GUI………………...………………………………………….15
Surface Water Detection System (SWDS) Product Description
3
List of Tables
Table 1. Competition Matrix…………………………………………………………..…12
Table 2. Prototype vs. Real-World Implementation Comparison…………………….….14
Table 3. Feature Comparison…………………………………………………………….16
Table 3. Prototype Assumptions…………………………………...…………………….17
[This space intentionally left blank]
Surface Water Detection System (SWDS) Product Description
4
Lab 1 – SWDS Product Description
1
INTRODUCTION
In the United States, floods are one of the most frequently occurring natural
disasters (FEMA, 2010). Unfortunately for drivers, there currently is no contiguous alert
system to warn when roadways are flooded and therefore unsafe to travel. With no
system currently in place, drivers are forced to use their own judgment for both the water
depth and the amount of water safe for their vehicle to pass through. This is not an easy
decision to make and this human error can result in vehicle damage and personal injury.
Tens of thousands of cars are damaged by floodwaters every year (CARFAX,
n.d.). Drivers whose vehicles can be repaired incur large costs where as others may even
need to purchase a completely new car. The costs associated with the vehicle damage are
nothing compared to those of hospital bills and in some instances the cost of one’s life.
According to the National Climatic Data Center (2005), 42% of fatalities caused by
flooding involved vehicles in the United States.
While the safety of the average American driver is the biggest concern, a city
incurring large costs because of flooded roadways is also an issue. The work force
needed to rescue stranded motorists, as well as resources needed to block off roadways to
prevent any more accidents both cost time and money. When vehicles are waterlogged
and therefore cannot be driven, they are towed at the city’s expense.
An effective alert system could help prevent vehicle damage, personal injury, and
extraneous use in city resources in situations where a driver cannot accurately assess the
water depth in the roads. The Surface Water Detection System (SWDS) was developed to
aid drivers in evaluating road conditions during flooding. SWDS is designed to detect
Surface Water Detection System (SWDS) Product Description
5
when roadways have a level of water deemed unsafe for vehicles to drive through without
causing damage. The system alerts drivers with the use of a warning sign on the road to
notify if a detour is necessary. With the use of the Google Maps API and RSS feeds,
drivers can also check road conditions before even starting their commute. The main goal
of the SWDS is to make drivers aware of flooding so they can take the necessary steps to
protect themselves and their vehicles.
2
PRODUCT DESCRIPTION
The SWDS is a hardware-oriented solution that detects the change in depth
between the road and the sensor. This information is then used to determine whether the
roads are safe for motorists. If a sensor detects flooding, a signal is sent to a localized
flashing road sign and to a centralized data center. The flashing road sign serves as an
immediate warning for current travelers. The centralized data center collects the
information through the networked system and allows a user to see a map of local road
flooding before they begin their drive. This information is also used in RSS feeds so the
user can get updates while away from the original web application. The data center stores
the information as well, which provides an archive for the user for historical and
statistical analysis.
2.1 Key Product Features and Capabilities
The Surface Water Detection System starts with our baseline package and has two
proposed upgrades. In Figure 1, the system is broken down into each package. “Remote”
represents the baseline package, “centralized control” represents the network package and
“End-User Applications” represents the application package. The baseline package
consists of a closed system setup. This closed system would be ideal for remote locations.
Surface Water Detection System (SWDS) Product Description
6
A sensor in a ruggedized housing would be installed along with a warning sign. The
microcontroller that controls the sensor has the ability to store a limited amount of data
for historical or statistical analysis. The system would allow embedded algorithms for
determining erroneous data for a more accurate alert.
Figure 1. Technical Overview
The first upgrade to this baseline package is a networked system of sensors. A
centralized data center would receive real-time data from multiple sensors at a given
time. While the baseline package would be ideal for rural or isolated locations, the
networked system would be ideal for more urban environments. The SWDS could either
utilize an existing network or our company would outsource to a network development
firm. With a networked system, software would be provided to monitor the sensors and
log any data received.
The second upgrade gives the user the full SWDS experience. The application
package upgrade would give the customer development support for implementing user
based applications. These applications can utilize the Google Maps API to show
interactive maps of where roads are flooded currently. The customer may also want to set
up a website that sends out RSS feeds to users to get road condition updates. The user
would sign up for updates on their commute route and detour accordingly if the roadways
are flooded. The application package upgrade would include both the baseline and
network packages.
Surface Water Detection System (SWDS) Product Description
7
2.2 Major Components (Hardware/Software)
In Figure 2, the hardware overview for the SWDS is outlined. The sensor,
microcontroller and network interface are all at a remote location in a ruggedized
housing. On the baseline system, the data from the sensor is sorted by the
microcontroller. An embedded algorithm is then used to sort any erroneous data and
determine if the roadway is deemed unsafe to drive. If a roadway is flooded, the
microcontroller sends a signal to the warning sign, which flashes to alert drivers to take a
detour.
The additional hardware components needed for the networked and application
package upgrades are illustrated in the second half of Figure 2. Our networked system
would have a centralized data control center that holds a server for data collection. This
server would then feed data that was collected to the web server and database used in the
application package upgrades.
Figure 2. Hardware Component Diagram
Figure 3 shows the connection between the warning sign and the microcontroller
as well. Each system will have an ultrasonic sensor, an intelligent microcontroller and a
Surface Water Detection System (SWDS) Product Description
8
conveniently located roadside warning sign. The networked package would include the
network interface card and centralized data center and the application package would
include a web server. The centralized data center would connect all the remote sensors,
log the data collected from these sensors and make it available to the web server. The
web server would then be used to continuously update the Google Maps interactive flood
maps and RSS feeds.
Figure 3. Major Functional Component Diagram
Though our solution is hardware-oriented, there are many software aspects
included. The ultrasonic sensor is programmed to monitor the distance between itself and
the ground. The closed system microcontroller is programmed to determine if the data
received is valid. The microcontroller is also programmed to turn the warning sign on and
off and transmit data collected back to the centralized data center. The software on the
collection unit in the centralized data center is used to organize and communicate realtime data to the web server.
Surface Water Detection System (SWDS) Product Description
9
Figure 4 gives a very simplistic illustration between the network’s data center and
the web server. The web server will host the customer’s website and provide syndication
services. This website will house the Google Maps application and allow users to sign up
for RSS feed updates on frequently traveled roadways.
Figure 4. Software Breakdown
The software included with the networked system will allow the user to easily
find historical data for each sensor. In Figure 5, the user inputs the sensor ID number as
well as the date and times desired. The depth measurements are then displayed for each
time slot in the data logs. This data can be used for statistical analysis or can assist car
insurance companies in allowing claims. If the driver was warned by our system that the
roadways were flooded, they should not have proceeded to drive through the area and
thus the damage to their vehicle would be their fault.
[This space intentionally left blank]
Surface Water Detection System (SWDS) Product Description 10
Figure 5. Insurance Agency GUI
There is also a user-friendly interface to look at the real-time sensor data. In
Figure 6, the depth measurements for each sensor are listed in inches. The sensor’s color
changes to indicate possible flooding, as well as when the roadways are determined to be
unsafe to drive. The yellow sensor warning indicates a potential for flooding and as the
depth increases, the warning gets more severe to orange and then to red indicating a
flooded roadway. This real-time data is also used to ensure each sensor is working
properly. If a sensor jumps from no warning to a red flood warning, it could indicate
debris in the road or a sensor malfunction. In either case, a city engineer can assess the
situation and find a quick solution.
Surface Water Detection System (SWDS) Product Description 11
Figure 6. City User GUI
2.3 Target Market/Customer Base
Although the main benefactor from this product is the average driver, the primary
customers consist of city governments. When roads flood and become hazardous to
drivers, it is the local government’s responsibility to assist motorists who may become
stranded or injured as a result. It is also their responsibility to try to prevent drivers from
passing through the waters. Currently, cities block off roadways with police cars and use
police officers and rescue workers to help divert traffic. This extraneous use of resources,
along with the cost of towing or rescuing stranded drivers, adds to the city’s expenses.
Aside from decreasing ancillary costs, the local government will build good public
relations by being concerned with the safety of its citizens. The decrease in flood-related
accidents will not only make the city look appealing, but will give the voters confidence
in choosing the incumbent for re-election. Though with city governments the system
would be sold through bid proposals, our product has a commercial front-end that allows
it to be sold to private citizens, as well.
Surface Water Detection System (SWDS) Product Description 12
Individuals can benefit from the Surface Water Detection System if they have a
particular interest in knowing water levels at a given time. This could be especially useful
for those living near water or whose house is below sea level. The SWDS could be used
to detect the water levels at a boat dock or to give homeowners peace of mind that they
will not come home to a flooded basement.
In Table 1, it is evident that our product offers the widest range of features. All
other competitors have road-embedded sensors, which makes it less portable to
homeowners and private citizen use. This portability allows SWDS to market to both city
governments and individuals.
Table 1. Competition Matrix
3 SWDS PRODUCT PROTOTYPE DESCRIPTION
The prototype of the SWDS solution demonstrates the feasibility of using an
ultrasonic sensor to determine if a roadway is flooded. The prototype allows us to
demonstrate how the sensor data sorting algorithms will work, as well as allow us to
simulate a networked system of sensors. Sample data that is simulated from the prototype
sensor and networked system will supply information to our web-based applications as
well.
Surface Water Detection System (SWDS) Product Description 13
The prototype will serve as a demonstration to mitigate any risks associated with
the final solution and proving the real world product concept for the customer. The
prototype will need to be limited to one actual sensor for simplicity. A networked system
will be generated in a simulation to demonstrate the software we are developing for the
network and to collect data for our web-based solutions. The Google Maps and RSS feed
aspects of our real world product will be demonstrated with our simulated data from the
networked system.
3.1 Prototype Goals and Objectives
The main goal of our prototype is to show proof of concept to our customers so that
they feel confident purchasing the real world product. The prototype must demonstrate all
features of the real world product through simulated data. Though the main software
components would be the same between the prototype and real world product, the
hardware is much different for a cost effective demonstration. In Table 2, the prototype
components are compared to those of the real world product to illustrate the main
difference between the two systems.
[This space intentionally left blank]
Surface Water Detection System (SWDS) Product Description 14
Table 2. Prototype vs. Real-World Implementation Comparison
By using an actual sensor, we can demonstrate the sensor’s ability to find the
depth. We can also show how our algorithm will sort data to determine whether the roads
are flooded or if debris or cars are causing erroneous readings. All of the data from the
sensor is sent to the microcontroller, which acts as an intermediate to our database that
will store the simulated information. The only difference between our web application
packages in the prototype versus the real world product would be the customizable wed
front to store both the Google Maps interactive maps and the RSS feed sign up. Both the
Google Maps demonstration and RSS Feed are available in our prototype.
Surface Water Detection System (SWDS) Product Description 15
3.2 Prototype Architecture
Our prototype solution is more software-oriented than the real world product. The
major hardware components of the prototype include a single ultrasonic sensor and a
Personal Computer. The software components include software to generate four
additional simulated sensors, the database used to store the information from the sensors
and the web-based applications.
Figure 7 shows an interactive map of Norfolk, Virginia that will be used in our
prototype to demonstrate the web-based applications. Balloons will be set at each sensor
location, color-coded for a user-friendly look at water depth warnings. The user can also
click on the balloons to see exact depth measurements.
Figure 7. General Public GUI
Surface Water Detection System (SWDS) Product Description 16
3.3 Prototype Features and Capabilities
The SWDS prototype shares many of the same features and capabilities of the real
world product. The prototype is able to calculate depth measurements and stores this
information for historical and statistical analysis. The information can also be passed to
our web-based applications in our prototype. In Table 3, a feature comparison is used to
show the similarities in the real world product and prototype.
Features
Real World Product
Prototype
Depth measurements
Included
Included
Data archive
Included, stored on
database.
Google Maps
Included for both
microcontroller and
centralized data center
(server).
Included
RSS feed
Included
Included, Norfolk is used as
an example.
Included
Customizable web-front
Included
Not Included
Table 3. Feature Comparison
The main difference in capabilities for the real world product and prototype would
be the simulated multi-sensor network as opposed to having an actual networked system.
The prototype assumes that none of the sensors stop functioning in the simulation. There
is also an assumption that any spike in data is an obstruction other than water and can
therefore be disregarded. Other assumptions for the prototype are listed in Table 4.
[This space intentionally left blank]
Surface Water Detection System (SWDS) Product Description 17
Prototype Assumptions
A simulated sensor will not stop functioning during a simulation.
Any spike in data will be regarded as an obstruction (such as a vehicle) and will be
thrown out.
The user will not look up data archives for a date that precedes the sensor installation
date.
The microcontroller will not perform any data processing; it is assumed that software at
the centralized data center will perform this task.
Table 4. Prototype Assumptions
With these assumptions, the prototype will effectively demonstrate the real world
product capabilities. The physical sensor will prove that our ultrasonic sensors can
calculate depth measurements and the simulated sensors will show an effective multisensor network. The prototype will be able to show the customer the random data
simulated for these sensors and how it will be stored for archival purposes. Our webbased applications are available in our prototype to demonstrate the full system with all
of the upgrade packages.
3.4 Prototype Development Challenges
The main challenge faced when developing this prototype will be working on the
hardware and software aspects in parallel. The software and hardware specialists will
need to effectively communicate to each other so that the modularized system can come
together. Though our prototype is not as hardware-oriented as our real world product, the
ultrasonic sensor still needs to be programmed to read the depth measurements and send
the data to the Personal Computer with the simulation software installed.
Surface Water Detection System (SWDS) Product Description 18
The hardware specialist that will be programming the sensor needs to make sure
the data feed is compatible with the software. Our software engineer will ensure that this
data feed is sent to the database and stored for archival purposes. He will also need to
work with the Google Maps API and RSS API to allow each to retrieve data from our
database. The information will then be used to fill in the map and send out customizable
alerts respectively.
Another challenge in developing the prototype is determining an appropriate
filtering algorithm. Our lead programmer will need to determine a looping interval for the
sensor data and judge what kind of data will be considered erroneous due to traffic or
other obstructions. The erroneous data should be caught before it is stored in the database
and should not trigger the roadside warning sign.
The final challenge in developing our prototype would be losing key members of
the group. If one of our more important developers cannot meet a deadline due to family
responsibilities or other projects, it will be the job of the project manager to re-delegate
the workload. Most of our developers are the team’s experts in that particular field, so it
will prove especially difficult for a new team member to pick up the slack and keep the
quality of work on the same level as our experts. If our team can avoid any problems in
communication, generate the proper algorithms and maintain all key developers, the
prototype development should not have any foreseeable problems.
Surface Water Detection System (SWDS) Product Description 19
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.
Surface Water Detection System (SWDS) Product Description 20
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 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 that 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.
Surface Water Detection System (SWDS) Product Description 21
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 in-turn, 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 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.
Web Server: A computer that delivers content from websites over the Internet.
Surface Water Detection System (SWDS) Product Description 22
REFERENCES
CARFAX Flood Car Tips: Avoid flood-damaged cars, autos, and vehicles. (n.d.).
CARFAX - Vehicle History Reports and VIN number check. Retrieved February
7, 2011, from http://www.carfax.com/car_buying/flood_damage_cars.cfx
Flood Maps, Insurance, and Information. (2010, August 11). FEMA. Retrieved February
7, 2011, from www.fema.gov/hazard/flood/info.shtm
Storm Data Publications. (2010, April 8). NCDC Climate Products. Retrieved February
7, 2011, from www.ncdc.noaa.gov/oa/climate/sd/