LAB 1 – Surface Water Detection System Product Description
Running head: LAB 1 – Surface Water Detection System Product Description
Lab 1 – Surface Water Detection System Product Description
Marissa Hornbrook
CS411
Professor Price
Old Dominion University
March 16, 2011
Version Three
1
LAB 1 – Surface Water Detection System Product Description
TABLE OF CONTENTS
1. INTRODUCTION ........................................................................................................ 3
2. PRODUCT DESCRIPTION ........................................................................................ 3
2.1. Key Product Features and Capabilities ................................................................... 4
2.2. Major Components (Hardware/Software) ............................................................... 6
2.3. Target Market/Customer Base ................................................................................. 8
3. SWDS PRODUCT PROTOTYPE DESCRIPTION ................................................ 10
3.1. Prototype Functional Goals and Objectives .......................................................... 10
3.2. Prototype Architecture ........................................................................................... 11
3.3. Prototype Features and Capabilities ...................................................................... 12
3.4. Prototype Development Challenges ...................................................................... 14
GLOSSARY .................................................................................................................... 16
REFERENCES ............................................................................................................... 18
LIST OF FIGURES
Figure 1. Technical Overview ............................................................................................ 6
Figure 2. Major Functional Component Diagram .............................................................. 5
Figure 3. Hardware Component Diagram .......................................................................... 7
Figure 4. Software Component Diagram............................................................................ 8
Figure 5. General Public GUI ........................................................................................... 12
Figure 6. City User GUI ................................................................................................... 13
Figure 7. Insurance Agency GUI...................................................................................... 13
LIST OF TABLES
Table 1. Competition Matrix .............................................................................................. 9
Table 2. Prototype vs. Real-World Implementation Comparison..................................... 11
Table 3. Prototype Assumptions ....................................................................................... 15
2
LAB 1 – Surface Water Detection System Product Description
1
3
INTRODUCTION
The purpose of this paper is to serve as an abstract for the surface water detection system
product, detailing both the societal issue that has been identified, and the corresponding solution.
During heavy rainfall and flooding, it is not uncommon to find that some drivers have
endeavored to drive through a flooded portion of road and have become stuck. This occurs when
water levels on the road are high enough to reach the vehicles’ electric system, causing it to
short-circuit and shut down. Currently, many roadways that are prone to flooding lack a city
controlled, contiguous alert system to warn drivers of hazardous water levels. Such a system
could assist drivers in preventing said vehicle damage and personal injury in cases where they
attempt passage through flooded sections of road. This negative impact is what our team aims to
eradicate through the creation of the Surface Water Detection System via its hardware and
software components. We will show feasibility through comprehensive documentation of our
prototype, as well as technical plans for the real-world implementation of the end product.
2
PRODUCT DESCRIPTION
As best practices dictate, we do not assume the type of product a client will desire until a
consultation is held, and a needs assessment is performed. To be versatile in our marketing
approach and because we realize client needs may differ, we offer a modularized solution whose
options include a closed system, a networked system, and individual upgrades. If desired, these
upgrades utilize the collected data for end user applications.
[This space intentionally left blank]
LAB 1 – Surface Water Detection System Product Description
4
A basic closed system consists of an ultrasonic sensor wired to a single microcontroller,
which sends a signal to a road sign that will flash when the water level is too deep. This is ideal
for remote locations that have a single trouble spot or two because most likely, that area would
not require a complex network of sensors. The networked system entails a greater deal of
complexity because it consists of multiple sensors that are connected, and which report water
depth to a centralized location for archival and manipulation by user applications. There are a
number of applications that we envision creating with the data collected from the sensor
network, and these will be discussed in detail further in this text.
2.1.
Key Product Features and Capabilities
Both the closed and networked options utilize a device called an ultrasonic sensor which
detects the distance between itself and the ground. In order to alert the driver of the road hazard,
each sensor on the network is mounted above-ground and aimed at a target location somewhere
on the road. Industrial strength sensors have an accuracy range of 26’ (Parallax), which is an
adequate distance for the purpose we have designed. The sensors are wired to a microcontroller,
which is then used to send a signal to a road sign that will flash when triggered. With the
networked choice, upon performing the distance measurement, the sensor will report the data to a
centralized data center via a wired or wireless network. The centralized data center is simply a
database located on a server that will have enough storage space to accommodate receiving a
constant stream of real time measurements. Once the information is stored in a database, it is
easily accessed via a user friendly website for reporting purposes. In Figure 2, the major
functional components are shown in their relation to one another to demonstrate how they
interact.
LAB 1 – Surface Water Detection System Product Description
5
Roadside
Warning Sign
Remote Device
Ultrasonic
Sensor
Embedded
Microcontroller
Internal Data
Store
Data Center
Web Server
Figure 2. Major Functional Component Diagram
The closed system is simply responsible for taking the distance measurement and sending
a signal to the road sign if the height of the water reaches the pre-programmed trigger. The cost
is lower to implement this system since there is no need for a centralized server, multiple sensors
with their associated microcontrollers, and the user software produced on the application side to
manipulate the data. Given that the networked system is a web-based solution, it naturally
follows that web applications would be created to use the data that has been gathered. We
envision that our prototype will be profitable when used to tie into the applications that we
create. The platform for these applications is the products’ own website which will have a
mapping component, such as Bing Maps™, prominently displayed. We have the ability to
manipulate the Bing Maps™ API and we will do so to add points of interest on the map where
our sensors indicate flooding. This will aid travelers in planning an optimal route to their
destination, which will allow them to bypass areas that are inundated with water. Because the
sensors report water depth as frequently as once every second, it is considered real-time software
and can be used to broadcast a Really Simple Syndication (RSS) feed to the product website.
This tool can be used by weather stations and various media outlets to report on the current status
of the water in different locations of the city. Users would simply need to subscribe to the feed to
get updates and begin utilizing the information.
LAB 1 – Surface Water Detection System Product Description
6
Figure 1. Technical Overview
One additional use for the data collected is in the car insurance industry. If a particular
insurance company can use the report service generated from the product website to specify and
view the weather conditions at the time their policyholder reports a claim for a flooded vehicle,
the company can deny the claim if it is proven the driver was adequately warned by our system.
This would save the insurance company money and would attest to be well worth the fee they
would pay to query our database for this information.
2.2.
Major Components (Hardware/Software)
As demonstrated in the introduction and key features description, this solution is
extremely hardware intensive. It relies on physical hardware pieces like the ultrasonic sensor,
microcontroller, server, and associated wiring to perform the majority of the work. The software
components include the product website, filtering logic, as well as the user applications
mentioned previously. The filtering logic is a necessary part of the software because without it,
the data would be inaccurate due to outside elements influencing the reading. For example, the
sensor may be placed in a particular section of road where cars are stopped in a traffic jam. The
sensor will function properly, but the distance it will read is to the top of the nearest car, not the
ground. This is an example of a reading we would discard as being erroneous data. Our software
will feature the capability to throw out this type of inaccuracy.
LAB 1 – Surface Water Detection System Product Description
7
Another case that needs to be accommodated and tested for is that of weather elements
other than rain. If a sensor reads in data that appears to be a rain measurement yet the outside
temperature is below 32°, it is most likely snow that is being detected. The filter logic will also
accommodate these scenarios as to report the most accurate information. The snow example will
also change the icon from rain to snow when displayed on the Bing Maps™ part of the product
website.
Under the closed system, the warning sign will flash when the water is too deep to pass,
and draws attention to the issue of an internal data store. To clarify, this is referring to the fact
that if the sensor is not relaying information via a network, the only way to store and archive the
data is internally by way of the microcontroller. The microcontroller is capable of storing this,
and there are several ways to retrieve this data on a regular basis, and we title this a ‘data
acquisition mechanism’. With the networked system, we leave the option open for the instance
that the city has an existing network we can tie into. Figure 3 shows the overview of the
hardware use in the SWDS solution.
Figure 3. Hardware Component Diagram
LAB 1 – Surface Water Detection System Product Description
8
The purpose of the sensors should be clear at this point, as well as the way data flows
across the network to be collected and used for multiple purposes. Just as the hardware has been
outlined, our software should also be detailed. The Data Acquisition Client depicted in Figure 4
is the microcontroller, and it is referencing its storage of the data. The Data Acquisition Host
refers to the server that collects the data to be stored in the database for archival/retrieval. The
web data servers’ job is essentially to host the product website and provide the RSS service.
Remote Device
Development PC
Data
Acquisition
Client
Data
Acquisition
Host
Control
Software
Database
User
Applications
Figure 4. Software Component Diagram
2.3.
Target Market/Customer Base
As a team, we have identified our primary target market as local city government. We
believe that in communicating with city engineers to find a solution that works best for their
individual needs, we can customize a solution and submit our idea through a bid proposal. As an
alternative to marketing to local cities, we have identified two other types of customers that can
benefit from our system. The first is the previously mentioned insurance agencies, who may be
able to take advantage of our product to lower the annual cost of policyholder claims as well as
decrease the rate of auto insurance fraud. The second customer is more ambiguous, being any
individual with water detection needs. The SWDS team thinks of this being helpful to clients
who have basements prone to flooding, those who live near large bodies of water where
hurricanes are common, or those who own watercraft that would like to monitor water depth.
LAB 1 – Surface Water Detection System Product Description
9
We organized and commissioned a research and development task force to investigate
market competition, ensuring that we not only have a product that is functional, but will be
competitive in an original way that is cost-effective. What the results show is that in-ground
sensors are the most prevalent in systems vaguely similar to ours in the water detection sense
alone. As Table 1 lists, some companies or city entities offer in-ground sensors but do not have a
commercial frontend or other components that our design incorporates. The in-ground sensors
are at greater cost to implement because the process to embed them in the ground requires a slab
of concrete to be poured at every sensor location. This defeats our goals of not only keeping the
product dynamic and modular, but also cost-effective. The idea is that if a sensor is no longer
needed in a particular area, it can be simply dismounted from its ruggedized housing and
relocated versus the alternative of digging up concrete and patching the area.
Table 1. Competition Matrix
[This space intentionally left blank]
LAB 1 – Surface Water Detection System Product Description
3.
10
SWDS PRODUCT PROTOTYPE DESCRIPTION
The prototype of the SWDS solution is designed to demonstrate that the concept is
feasible to implement, and the product website/user applications are user-friendly. It allows us to
show what is possible within a smaller scope than the real-world implementation, to serve as
proof of concept. In order to demonstrate this, it is essential for the SWDS team to eliminate
extraneous components of the networked solution, namely the existing network to tie into. We
will be operating our prototype demonstration in a simulation environment to fill the void where
physical implementation is not practical.
3.1
Prototype Functional Goals and Objectives
The overall objectives for this project are to demonstrate that: The ultrasonic sensor
functions properly by accurately sensing water depth, relays a message to trigger the road sign,
filters out erroneous data, and properly archives it for report retrieval. There is a differentiation
between the prototype in this stage of development and the real-world product implementation,
whose differences are displayed in Table 2. Each major component is detailed according to their
changes from one phase to another.
[This space intentionally left blank]
LAB 1 – Surface Water Detection System Product Description
Feature
Real World Implementation
Sensor
One sensor available for closed
system; multiple sensors for
networked system. Ruggedized
housing to protect from the
elements.
For closed system, embedded
data store and algorithms to
throw out erroneous data. For
networked solution, programmed
to send data to centralized data
center.
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.
Data collection server that stores
the info from the microcontroller
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.
Featured on the product website
with real-time water depth
measurements in inches.
Microcontroller
Multi-Sensor Network
Centralized Data Center
Report Generator
BingMaps™ application
RSS
Included on the product website
for entities to subscribe.
11
Prototype
Will feature one sensor that
detects and sends data to the
simulation computer in the
closed system demonstration.
Will feature one microcontroller
that receives data from a single
sensor and sends it to the
development PC.
This will be simulated for the
networked demonstration.
Will be simulated.
This is simulated in a GUI on the
development computer.
Will be simulated on the product
website via a GUI.
An icon will be featured on the
product website but will not be
functional.
Table 2. Prototype vs. Real-World Implementation Comparison
3.2
Prototype Architecture
In keeping with the definition of a prototype, the major functional components of the
SWDS prototype are simply a scaled-down model of the real-world product. The prototype will
still continue to retain the functionality of the end product but will operate primarily in a
simulated environment to show all test cases. The architecture consists of a development PC, as
well as the ultrasonic sensor and microcontroller hardware interfaces.
LAB 1 – Surface Water Detection System Product Description
3.3
12
Prototype Features and Capabilities
In the prototype demonstration, the sensor will read the data and send it to a development
computer. At that point, the data will be assigned to variables which can be manipulated and fed
into a weather simulation program that we will create. The simulation program will cycle
through various test cases and weather scenarios, showing that presented with variables of
temperature and weather conditions (rain, sun, show, etc.) the sensor will accurately report the
data and be archived. In turn, after archival, the simulation will be able to demonstrate the ability
to pull reports from the database, and supply real-time data to the BingMaps™ component and
the simulated RSS feed.
During initial drafting of the software side of this prototype, a design team has created a
user-friendly graphical user interface (GUI) for each of the estimated use cases. The first is the
view displayed to the average user (general public) who types in the product website’s URL.
They will see a Bing Maps™ component on the homepage where they can input a location to
view sensors in that area.
Figure 5. General Public GUI
LAB 1 – Surface Water Detection System Product Description
13
The second view is for the client which we are targeting, a user from the city that has
purchased the SWDS. They will have the capability to view archives and generate reports to fit
their needs (See Figure 6). The third view is for the insurance agency user, demonstrating that
they can also pull reports based on the day/time in question (Figure 7).
Figure 6. City User GUI
Figure 7. Insurance Agency GUI
LAB 1 – Surface Water Detection System Product Description
14
The database will store the basic information of the sensor ID, the date and time (this will
be done automatically by timestamp from the microcontroller), and the rainfall in fractions of an
inch. In this example, we used the City of Norfolk as a baseline because the demographic is
familiar to the design team. The product website will be coded using a programming language
called ASP.NET and using logic code called C#. This follows current market trend for software
development and allows the developers to use the most advantageous and powerful tools.
3.4
Prototype Development Challenges
One of the forefront challenges on the development agenda is that of filter algorithm. It
will take members of the team dedicated to spending a large amount of time developing a
solution to effectively eliminate invalid data in the cases described earlier. A brainstorming
session will take place between the development team and the project manager to identify and
tackle each imagined test case where invalid data may be generated and reported to the system.
This difficult task will prove necessary for the prototype to be complete and allow transition to
the real-world implementation. Another perceived challenge is that of adequate testing on the
development machine. A development session will be held to discover each possible test case
with which to run the test data and review the simulated results. Thorough testing ensures a solid
product that will have a lesser probability of defect when implemented by a client in the actual
business market. The benefits to this simulation clearly outweigh the challenges, because by
fixing any errors in the algorithm or prototype simulation as a whole, it will be ready for
marketing and production in later development phases.
[This space intentionally left blank]
LAB 1 – Surface Water Detection System Product Description
15
We propose that in order for the prototype to function properly within the scope of the
product, certain assumptions must be made. We have decided the following must be assumed to
continue showing proof of concept (Table 3).
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 3. Prototype Assumptions
LAB 1 – Surface Water Detection System Product Description
16
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.
Bing Maps API: A technology created by Bing 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 which involves breaking a unified process or idea into
coherent segments for the purpose of abstraction or simplicity.
LAB 1 – Surface Water Detection System Product Description
17
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.
URL: Uniform Resource Locator
User based 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.
Web Server: A computer that delivers content from websites over the Internet.
LAB 1 – Surface Water Detection System Product Description
REFERENCES
Parallax Industrial Sensors Retrieved February 9, 2011, from http://www.parallax.com
18