cpi/old/411/greens11/documents/eboyd/... · Web viewRunning head: Lab I – Surface Water Detection...

Lab I – Surface Water Detection System Description 1

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


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



LIST OF TABLES

Table 1. Competition Matrix..........................................................................................................10

Table 2. Prototype vs. Real-World Implementation Comparison..................................................15



1 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.


2 SWDS PRODUCT DESCRIPTION

2.1 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.



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.



2.2 Major 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.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 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.

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


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.



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



3.2 Prototype 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.



Feature Real World Implementation Prototype

Sensor 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.3 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 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.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 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.



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


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 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 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.

cpi/old/411/greens11/documents/eboyd/... · Web viewRunning head: Lab I – Surface Water Detection...

Documents

Transcript of cpi/old/411/greens11/documents/eboyd/... · Web viewRunning head: Lab I – Surface Water Detection...